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Preface 



Casl, the Common Algebraic Specification Language^ has been designed by 
CoFI, the Common Framework Initiative for algebraic specihcation and de- 
velopment. Casl is an expressive language for specifying requirements and 
design for conventional software. It is algebraic in the sense that models of 
Casl specihcations are algebras; the axioms can be arbitrary hrst-order for- 
mulas. 

Casl is a major new algebraic specihcation language. It has been care- 
fully designed by a large group of experts as a general-purpose language for 
practical use in software development - in particular, for specifying both re- 
quirements and design. Casl includes carefully selected features from many 
previous specihcation languages, as well as some novel features that allow al- 
gebraic specihcations to be written much more concisely and perspicuously 
than hitherto. It may ultimately replace most of the previous languages, and 
provide a common basis for future research and development. 

Casl has already attracted widespread interest within the algebraic spec- 
ihcation community, and is generally regarded as a de facto standard. Various 
sublanguages of Casl are available - primarily for use in connection with 
existing tools that were developed in connection with previous languages. Ex- 
tensions of Casl provide languages oriented toward development of particular 
kinds of software (reactive, concurrent, etc.). 

Major libraries of validated Casl specihcations are freely available on the 
Internet, and the specihcations can be reused simply by referring to their 
names. Tools are provided to support practical use of Casl: checking the 
correctness of specihcations, proving facts about them, and managing the 
formal software development process. 

This reference manual gives a detailed presentation of the Casl specihca- 
tion formalism. It reviews the main underlying concepts, and carefully summa- 
rizes the intended meaning of each construct of Casl. It formally dehnes both 
the syntax and semantics of Casl, and presents a logic for reasoning about 
Casl specihcations. It also provides extensive libraries of Casl specihcations 
of basic datatypes, and an annotated bibliography of CoFI publications. 
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The companion Casl User Manual (LNCS 2900) illustrates and discusses 
how to write Casl specihcations, introducing the potential user to the features 
of Casl mainly by means of illustrative examples. The User Manual also 
reviews the background of CoFI and Casl, and the underlying concepts of 
algebraic specihcation languages, as well as introducing the reader to some 
of the currently available Casl support tools, and to a couple of the Casl 
libraries of basic datatypes. Finally, the User Manual includes a substantial 
case study of the practical use of Casl in an industrially relevant context, and 
a Quick Reference overview of the Casl syntax. 



Structure 

Part I offers a dehnitive summary of the entire Casl language: all the lan- 
guage constructs are listed there systematically, together with the syntax used 
to write them down and a detailed explanation of their intended meaning. 
However, although it tries to be precise and complete, the Casl Summary 
still relies on natural language to present Casl. This inherently leaves some 
room for interpretation and ambiguity in various corners of the language, for 
example where details of different constructs interact. Such potential ambigu- 
ities are eliminated by the following formal dehnitions, which also establish 
sound mathematical foundations. 

Part II gives a formal dehnition of the syntax of Casl. Both concrete 
and abstract syntax are dehned by means of context-free grammars, using a 
variant of the BNF notation. 

The ultimate dehnition of the meaning of Casl specihcations is provided 
by the semantics of Casl in Part III. The semantics hrst dehnes mathemat- 
ical entities that formally model the intended meaning of various concepts 
underlying Casl, which were introduced and discussed throughout the sum- 
mary. The semantics is given in the form of so-called natural semantics^ with 
formal deduction rules to derive judgments concerning the meaning of each 
Casl phrase from the meanings of its constituent parts. 

The semantics is also a necessary prerequisite for the development of mech- 
anisms for formal reasoning about Casl specihcations. This is dealt with in 
Part IV, where proof calculi that support reasoning about the various layers 
of Casl are presented. Soundness is proved and completeness discussed by 
reference to the formal semantics of Casl. 

All this work on the mathematical underpinnings of Casl, as documented 
in this Reference Manual, should make the language exceptionally trustworthy 
- at least in the sense that it provides a formal point of reference against which 
claims may (and should) be checked. 

Finally, Part V presents extensive libraries of Casl specihcations of basic 
datatypes. These include specihcations of numbers (both bounded and un- 
bounded), relations and orders, simple and structured datatypes, graphs, and 
various mathematical structures. 
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The Reference Manual is concluded by an annotated bibliography, a list 
of cited references, an index of specihcation and library names (referring to 
Part V), a symbol index, and an index of concepts. 

An accompanying CD-ROM contains a copy of the libraries of specihca- 
tions of basic datatypes and a collection of Casl tools. 



Organization 

Casl consists of several major levels^ which are quite independent and may 
be understood (and used) separately: 

Basic specifications denote classes of partial hrst-order structures: algebras 
where the functions are partial or total, and where also predicates are 
allowed. Subsorts are interpreted as embeddings. Axioms are hrst-order 
formulas built from dehnedness assertions and both strong and existential 
equations. Sort generation constraints can be stated. Datatype declara- 
tions are provided for concise specihcation of sorts equipped with con- 
structors and (optional) selectors, including enumerations and products. 
Structured specifications allow translation, reduction, union, and extension of 
specihcations. Extensions may be required to be free; initiality constraints 
are a special case. A simple form of generic (parametrized) specihcations 
is provided, together with instantiation involving parameter-htting trans- 
lations. 

Architectural specifications dehne how the specihed software is to be com- 
posed from a given set of separately developed, reusable units with clear 
interfaces. 

Libraries allow the distributed storage and retrieval of (particular versions 
of) named specihcations. 

The Casl Summary in Part I is organized accordingly: after an introductory 
chapter, each level of Casl is considered in turn. The grammars for the ab- 
stract and concrete syntax of Casl in Part II are structured similarly. The 
chapters and sections of the Casl Semantics in Part III and of the Casl Logic 
in Part IV correspond directly to those of Part I. Thus readers interested in 
all aspects of one particular level of Casl should have no difficulty in locating 
the relevant chapters in each part, and similarly for all the sections dealing 
with a particular Casl construct. 

References to chapters within the same part give just the chapter num- 
ber, possibly following it by section and subsection numbers, e.g.. Chap. 4, 
Sect. 4.2.3. References to chapters in other parts are always preceded by the 
Roman numeral indicating the part, e.g.. Chap. III:4, Sect. 111:4.2.3. Similarly 
for references to propositions, etc. 
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Acknowledgement. The design of Casl and the preparation of this book have in- 
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Executive Editor, for their willingness to publish this book, and for helpful advice 
concerning its preparation. 

January 2004 Peter D. Mosses 
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Introduction 



This part of the Casl Reference Manual gives a detailed summary of the 
syntax and intended semantics of Casl. Readers are assumed to be already 
familiar with the main concepts of algebraic specihcations. 

Chapter 2 summarizes many- sorted basic specifications in Casl, which de- 
note classes of many-sorted partial hrst-order structures: algebras where the 
functions are partial or total, and where also predicates are allowed. Axioms 
are hrst-order formulas built from equations and dehnedness assertions. Sort 
generation constraints can be stated. Datatype declarations are provided for 
concise specihcation of sorts together with constructors and (optional) selec- 
tors. 

Chapter 3 summarizes subsorted basic specifications^ which extend many- 
sorted specihcations with a simple treatment of subsorts, interpreting subsort 
inclusion as embedding. 

Chapter 4 summarizes structured specifications^ which allow translation, 
reduction, union, and extension of specihcations. Extensions may be required 
to be free; initiality constraints are a special case. A simple form of generic 
specihcations is provided, together with instantiation involving parameter- 
htting translations and views. 

Chapter 5 summarizes architectural specifications^ which dehne how the 
specihed software is to be composed from a given set of separately-developed, 
reusable units with clear interfaces. 

Chapter 6 summarizes specification libraries^ which allow the (distributed) 
storage and retrieval of named specihcations. 

Finally, Chap. 7 (by Till Mossakowski) summarizes various sublanguages 
and extensions of Casl. 

In general, each chapter hrst summarizes the main semantic concepts un- 
derlying the kind of specihcation concerned, then it presents the (abstract and 
concrete) syntax of the associated Casl language constructs and indicates 
their intended semantics. See Part II of this reference manual for complete 
grammars for the abstract and concrete syntax of Casl, and Part III for the 
formal semantics of Casl. 
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1:1 Introduction 



This summary does not attempt to motivate the design choices that have 
been taken; a rationale for a preliminary design has been published separately 
[49], as has a full exposition of architectural specihcations [6]. See also [1] for 
a concise overview of Casl, and [5] for a tutorial introduction. 

Acknowledgement. The CoFI Language Design Group was formed at the founding 
meeting of the Common Framework Initiative in Oslo, September 1995. Language de- 
sign working meetings were held in Paris (November 1995), Munich (January 1996), 
Oxford (March 1996), Paris (May 1996), Munich (July 1996), Edinburgh (Novem- 
ber 1996), Paris (January and April 1997), Amsterdam (September 1997), Bremen 
(January 1998), Lisbon (April 1998), Amsterdam (April 1999), Berlin (April 2000), 
and Genova (April 2001). The earlier meetings were mostly hosted by Michel Bidoit, 
Bernd Krieg-Briickner, Don Sannella, and Martin Wirsing; the later meetings were 
CO- located with major conferences. Notes recording the discussions and decisions at 
the meetings were produced by Christine Choppy. 

The following persons contributed to the design of Casl- some of them over 
many years, others only occasionally - by studying the issues and making sug- 
gestions: Egidio Astesiano, Hubert Baumeister, Jan Bergstra, Gilles Bernot, Di- 
dier Bert, Mohammed Bettaz, Michel Bidoit, Mark van den Brand, Maria Victo- 
ria Cengarle, Maura Cerioli, Christine Choppy, Pietro Cenciarelli, Ole-Johan Dahl, 
Hans-Dieter Ehrich, Hartmut Ehrig, Jose Fiadeiro, Marie-Claude Gaudel, Chris 
George, Joseph Goguen, Radu Grosu, Magne Haveraaen, Anne Haxthausen, Jim 
Horning, Helene Kirchner, Kolyang, Hans-Jorg Kreowski, Bernd Krieg-Briickner, 
Pierre Lescanne, Christoph Liith, Tom Maibaum, Grant Malcolm, Karl Meinke, 
Till Mossakowski, Peter Mosses, Peter Padawitz, Fernando Orejas, Olaf Owe, Gi- 
anna Reggio, Horst Reichel, Markus Roggenbach, Erik Saaman, Don Sannella, 
Giuseppe Scollo, Amilcar Sernadas, Andrzej Tarlecki, Christophe Tronche, Eelco 
Visser, Frederic Voisin, Eric Wagner, Michal Walicki, Bjarke Wedemeijer, Martin 
Wirsing, Uwe Wolter, and Alexandre Zamulin. 

The acronym CASL for the Common Algebraic Specification Language was pro- 
posed by Christine Choppy. 

The design of the abstract syntax and semantics of CASL was much influenced 
by the work of the CoFI Semantics Group, mainly consisting of Hubert Baumeister, 
Maura Cerioli, Anne Haxthausen, Till Mossakowski, Don Sannella, and Andrzej 
Tarlecki. (See Part II regarding the design of the concrete syntax.) 

The IFIP WG1.3 Referees’ Report on CASL reviewed the initial design pro- 
posal for Casl (version 0.97, May 1997); the CASL Designers’ final response to the 
referees indicated how the points raised in the report had influenced the final de- 
sign (version 1.0.1-DRAFT, June 2000, approved and released as version 1.0.1 in 
March 2001)^. The IFIP WG1.3 reviewers consisted of Hartmut Ehrig (Coordina- 
tor), Jose Meseguer, Ugo Montanari, Fernando Orejas, Peter Padawitz, Francesco 
Parisi-Presicce, Martin Wirsing, and Uwe Wolter. 

The coordinator of the Language Design task group during the design of CASL 
was Bernd Krieg-Briickner. 



^ The original design documents and the reviews are available from the CoFI 
Archives [16]. 
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Basic Specifications 



Basic specifications in Casl allow declaration of sorts, subsorts, operations 
(both total and partial), and predicates, and the use of formulas of first-order 
logic for stating axioms. Subsorts can be defined by formulas. Sorts can be con- 
strained to include only generated values. Both loose and free datatypes with 
constructor and (optionally) selector operations can be declared concisely. 

Section 2.1 introduces the concepts underlying many- sorted basic speci- 
fications, and the remaining sections cover the language constructs provided 
by Casl for use in such specifications: Sect. 2.2 describes the overall structure 
of basic specifications; Sect. 2.3 introduces declarations of sorts, operations, 
and predicates; Sect. 2.4 deals with variable declarations; Sect. 2.5 summa- 
rizes the formulas and terms used in axioms; and Sect. 2.6 indicates the form 
of identifiers. The concepts and Casl constructs concerned with subsorts are 
summarized separately, in Chap. 3. 

2.1 Basic Concepts 

First, before considering the particular concepts underlying basic specifica- 
tions in Casl, here is a brief reminder of how specification frameworks in gen- 
eral may be formalized in terms of so-called institutions [20] (some category- 
theoretic details are omitted) and proof systems. 

A basie speeifieation framework may be characterized by: 

• a class Sig of signatures A, each determining the set of symbols \U\ whose 
intended interpretation is to be specified, with morphisms between signa- 
tures; 

• a class Mod(A) of models^ with homomorphisms between them, for each 
signature U; 

• a set Sen(A) of sentenees (or axioms)^ for each signature A; 

• a relation ^ of satisfaetion^ between models and sentences over the same 
signature; and 

• a proof system., for inferring sentences from sets of sentences. 

A basie speeifieation consists of a signature U together with a set of sentences 
from Sen(A). The signature provided for a particular declaration or sentence 
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in a specification is called its local environment It may be a restriction of the 
entire signature of the specihcation, e.g., determined by an order of presen- 
tation for the signature declarations and the sentences with linear visibility^ 
where symbols may not be used before they have been declared; or it may be 
the entire signature, reflecting non-linear visibility. 

The (loose) semantics of a basic specihcation is the class of those models 
in Mod(i7) which satisfy all the specihed sentences. A specihcation is said to 
be consistent when there are some models that satisfy all the sentences, and 
inconsistent when there are no such models. A sentence is a consequence of a 
basic specihcation if it is satished in all the models of the specihcation. 

A signature morphism a : U ^ U' determines a translation function 
Sen(cr) on sentences, mapping Sen(A) to Sen(A'), and a reduct function 
Mod(cr) on models, mapping Mod(A') to Mod(A) Satisfaction is required 
to be preserved by translation: for all S G Sen(A),M' G Mod(A'), 

Mod(a)(M') ^ M' ^ Sen(a)(6'). 

The proof system is required to be sound, i.e., sentences inferred from a spec- 
ihcation are always consequences; moreover, inference is to be preserved by 
translation. 

Sentences of basic specihcations may include constraints that restrict the 
class of models, e.g., to reachable ones. 

The rest of this chapter considers many-sorted basic specihcations of the 
Casl specihcation framework, and indicates the underlying signatures, mod- 
els, and sentences^. Then the syntax of the language constructs used for ex- 
pressing many-sorted basic specihcations is described. Consideration of the 
extra features concerned with subsorts is deferred to Chap. 3 . The abstract 
syntax of any well-formed basic specihcation determines a signature and a set 
of sentences, the models of which provide the semantics of the basic specih- 
cation. 



2.1.1 Signatures 

A many-sorted signature U = (/S', TF ^ PF ^ P) consists of: 

• a set S' of sorts; 

• sets TF^^s^ PFw,s^ of total function symbols^ Tespectively partial function 
symbols^ such that TF^^g C PF^^g = 0 , for each function profile (re, 5) 
consisting of a sequence of argument sorts w ^ S* and a result sort 5 G S' 
{constants are treated as functions with no arguments); 

• sets P^ of predicate symbols, for each predicate profile consisting of a 
sequence of argument sorts re G S'*. 

^ In fact Sig is a category, and Sen(.) and Mod(.) are functors. The categorial as- 
pects of the semantics of Casl are emphasized in its formal semantics in Part III. 

^ A particular proof system for Casl is provided in Part IV. 
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Constants and functions are also referred to as operations^ following the tra- 
ditions of algebraic specification. 

Note that symbols used to identify sorts, operations, and predicates may 
be overloaded^ occurring in more than one of the above sets. To ensure that 
there is no ambiguity in sentences at this level, however, function symbols / 
and predicate symbols p are always qualified by profiles when used, written 
and p^ respectively. (The language described later in this chapter allows 
the omission of such qualifications when these are unambiguously determined 
by the context.) 

A many-sorted signature morphism a : (/S', TF ^ PF ^ P) (S", TP' ^ PF\ P') 

consists of a mapping from S to S", and for each w ^ ^ a mapping 

between the corresponding sets of function, resp. predicate symbols. A partial 
function symbol may be mapped also to a total function symbol, but not vice 
versa. 



2.1.2 Models 

For a many-sorted signature P = (S', TP , PF , P) a many-sorted model M G 
Mod(A) is a many-sorted first-order strueture consisting of a many-sorted 
partial algebra: 

• a non-empty earrier set for each sort 5 G S' (let denote the Carte- 
sian product X • • • X 5^ when w = si . . . 5^), 

• a partial funetion from to for each function symbol / G 

or / G PFw,s^ tfie function being required to be total in the former case, 

together with: 

• a predieate p^ C for each predicate symbol p ^ P^. 

A (weak) many-sorted homomorphism h from Mi to M 2 , with Mi, M 2 G 
Mod(S', TP , PF , P)^ consists of a function hg : for each 5 G S' 

preserving not only the values of functions but also their definedness, and 
preserving the truth of predicates [14]. 

Any signature morphism a : P ^ P' determines the many-sorted reduet of 
each model M' G Mod(A') to a model M G Mod(A), defined by interpreting 
symbols of A in M in the same way that their images under a are interpreted 
in Mb 



2.1.3 Sentences 

The many-sorted terms on a signature P = (S', TP ^ PF ^ P) and a set of sorted, 
non-over loaded variables X are built from: 

• variables from X; 

• applications of qualified function symbols in TF U PF to argument terms 
of appropriate sorts. 
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We refer to such terms as fully -qualified terms^ to avoid confusion with the 
terms of the language considered later in this chapter, which allow the omission 
of qualihcations and explicit sorts when these are unambiguously determined 
by the context. 

For a many-sorted signature U = (/S', TF ^ PF ^ P) the many-sorted sen- 
tences in Sen(i7) are the usual closed many-sorted hrst-order logic formulas, 
built from atomic formulas using quantihcation (over sorted variables) and 
logical connectives. An inner quantihcation over a variable makes a hole in 
the scope of an outer quantihcation over the same variable, regardless of the 
sorts of the variables. Implication may be taken as primitive (in the presence 
of an always- false formula), the other connectives being regarded as derived. 
The atomic formulas are: 

• applications of qualihed predicate symbols p G P to argument terms of 
appropriate sorts; 

• assertions about the dehnedness of fully-qualihed terms; 

• existential and strong equations between fully-qualihed terms of the same 
sort. 

Dehnedness assertions may be derived from existential equations or regarded 
as applications of hxed, always-true predicates. Strong equations may be de- 
rived from existential equations, using implication and conjunction; existential 
equations may be derived from conjunctions of strong equations and dehned- 
ness assertions, or regarded as applications of hxed predicates. 

The sentences Sen(A) also include sort- generation constraints. Let F = 
(/S', TP ^ PF^ P). A sort-generation constraint consists of (S",P') with S" C S' 
and F' C TF U PF 

2.1.4 Satisfaction 

The satisfaction of a sentence in a structure M is determined as usual by the 
holding of its atomic formulas w.r.t. assignments of (dehned) values to all the 
variables that occur in them, the values assigned to variables of sort s being in 
. The value of a term w.r.t. a variable assignment may be undehned, due to 
the application of a partial function during the evaluation of the term. Note, 
however, that the satisfaction of sentences is two-valued (as is the holding of 
open formulas with respect to variable assignments). 

The application of a predicate symbol p to a sequence of argument terms 
holds in M iff the values of all the terms are dehned and give a tuple belonging 
to . A dehnedness assertion concerning a term holds iff the value of the 
term is dehned (thus it corresponds to the application of a constantly-true 
unary predicate to the term). An existential equation holds iff the values of 
both terms are dehned and identical, whereas a strong equation holds also 
when the values of both terms are undehned. 

^ The translation of such constraints along signature morphisms adds a further 
component, for technical reasons. 
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The value of an occurrence of a variable in a term is that provided by the 
given variable assignment. The value of the application of a function symbol 
/ to a sequence of argument terms is dehned only if the values of all the 
argument terms are dehned and give a tuple in the domain of dehnedness of 
/^, and then it is the associated result value. 

A sort-generation constraint is satished in a A-model M if the 

carriers of the sorts in S' are generated by the function symbols in F'. That 
is, every element of each sort in S' is the value of a term built from just 
these symbols (possibly using variables of sorts not in S' ^ with appropriate 
assignments of values to them). 

The rest of this chapter indicates the abstract and concrete syntax of the 
constructs of many-sorted basic specihcations, and describes their intended 
interpretation. 

2.2 Basic Items 

For an introduction to the form of grammar used here to dehne the abstract 
syntax of language constructs, see Chap. 11:2, which also provides the com- 
plete grammar dehning the abstract syntax of the entire Casl specihcation 
language. 

BASIC-SPEC ::= basic-spec BASIC-ITEMS* 

A many-sorted basic specihcation BASIC-SPEC in the Casl language is written 
simply as a sequence of BASIC- ITEMS constructs: 

The empty basic specihcation is not usually needed, but can be written 

This language construct determines a basic specihcation within the under- 
lying many-sorted institution, consisting of a signature and a set of sentences 
of the form described at the beginning of this chapter. This signature and the 
class of models over it that satisfy the set of sentences provide the semanties 
of the basic specihcation. Thus this chapter explains well-formedness of basic 
specihcations, and the way that they determine the underlying signatures and 
sentences, rather than directly explaining the intended interpretation of the 
constructs. 

While well-formedness of specihcations in the language can be checked 
statically, the question of whether the value of a term that occurs in a well- 
formed specihcation is necessarily dehned in all models may depend on the 
specihed axioms (and it is not decidable in general). 

BASIC-ITEMS ::= SIG-ITEMS I FREE-DATATYPE | SORT-GEN 

I VAR- ITEMS I LOCAL- VAR- AXIOMS I AXIOM- ITEMS 

A BASIC- ITEMS construct is always a list, written: 

plural- keyword Xi; . . . 
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The plural- keyword may also be written in the singular (regardless of the 
number of items), and the hnal ‘ ; ’ may be omitted. 

Each BASIC- ITEMS construct determines part of a signature and/or some 
sentences (except for VAR- ITEMS, which merely declares some global variables). 
The order of the basic items is generally signihcant: there is linear visibility 
of declared symbols and variables in a list of BASIC- ITEMS constructs (except 
within a list of datatype declarations). Repeated declaration of a symbol is 
allowed, and does not affect the semantics; some tools may however be able 
to locate and warn about such duplications, in case they were not intentional. 

A list of signature declarations and dehnitions SIG- ITEMS determines part 
of a signature and possibly some sentences. A FREE-DATATYPE construct de- 
termines part of a signature together with some sentences. A sort-generation 
construct SORT-GEN determines part of a signature, together with some sen- 
tences including a corresponding sort generation constraint. A list of variable 
declaration items VAR- ITEMS determines sorted variables that are implicitly 
universally quantihed in the subsequent axioms of the enclosing basic speci- 
hcation; note that variable declarations do not contribute to the signature of 
the specihcation in which they occur. A LOCAL-VAR- AXIOMS construct restricts 
the scope of the variable declarations to the indicated list of axioms. (Variables 
may also be declared locally in individual axioms, by explicit quantihcation.) 
An AXIOM- ITEMS construct determines a set of sentences. 



2.3 Signature Declarations 

SIG-ITEMS ::= SORT-ITEMS I OP-ITEMS I PRED-ITEMS I DATATYPE -ITEMS 

A list SORT- ITEMS of sort declarations determines one or more sorts. A 
list OP- ITEMS of operation declarations and/or dehnitions determines one 
or more operation symbols, and possibly some sentences; similarly for a list 
PRED-ITEMS of predicate declarations and/or dehnitions. Operation and pred- 
icate symbols may be overloaded, being declared with several different prohles 
in the same local environment. A list DATATYPE- ITEMS of datatype declara- 
tions determines one or more sorts together with some constructor and (op- 
tional) selector operations, and sentences dehning the selector operations on 
the values given by the constructors with which they are associated. 



2.3.1 Sorts 

SORT-ITEMS ::= sort-items S0RT-ITEM+ 

SORT-ITEM ::= SORT-DECL 

A list SORT- ITEMS of sort declarations is written: 
sorts SIi\ . . . SIn\ 
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Sort Declarations 

SORT-DECL : := sort-decl S0RT+ 

SORT ::= SORT-ID 

A sort declaration SORT-DECL is written: 

It declares each of the sorts in the list 5i, . . . , 5^. 

2.3.2 Operations 

OP-ITEMS ::= op-items 0P-ITEM+ 

OP-ITEM ::= OP-DECL | OP-DEFN 

A list OP- ITEMS of operation declarations and dehnitions is written: 
ops Oh; ... Oh; 



Operation Declarations 

OP-DECL ::= op-deci 0P-NAME+ OP-TYPE OP-ATTR* 

OP-NAME ::= ID 

An operation declaration OP-DECL is written: 

/l 5 • • • 5 /n • TY , , . . . , ttjYi 

When the list ai , . . . , is empty, the declaration is written simply: 

TY 

It declares each operation name /i, . . . ^ fn as a total or partial operation, with 
prohle as specihed by the operation type TY ^ and as having the attributes ai, 
. . . , am (if any). If an operation is declared both as total and as partial with 
the same prohle, the resulting signature only contains the total operation. 

Operation Types 

OP-TYPE ::= TOTAL-OP-TYPE | PARTIAL-OP-TYPE 

TOTAL-OP-TYPE ::= total-op-type SORT-LIST SORT 

PARTIAL-OP-TYPE ::= partial-op-type SORT-LIST SORT 

SORT-LIST : := sort-list SORT* 

A total operation type TOTAL-OP-TYPE with some argument sorts is written: 

Si X ... X Sn ^ s 
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When the list of argument sorts is empty, the type is simply written ‘ 5 ’. The 
sign displayed as ‘x’ may be input as ‘x’ in ISO Latin-1, or as in ASCII. 
The sign displayed as is input as 

A partial operation type PARTIAL- OP-TYPE with some argument sorts is 
written: 

5i X . . . X 5^ S 

When the list of argument sorts is empty, the type is simply written ‘? s\ 
The operation prohle determined by the type has argument sorts 5i , . . . , 
Sn and result sort s. 

Operation Attributes 

OP-ATTR ::= BINARY-OP-ATTR | UNIT-OP-ATTR 

BINARY-OP-ATTR : := assoc-op-attr | comm-op-attr | idem-op-attr 
UNIT-OP-ATTR : := unit-op-attr TERM 

Operation attributes assert that the operations being declared (which must 
be binary) have certain common properties, which are characterized by strong 
equations, universally quant ihed over variables of the appropriate sort. (This 
can also be used to add attributes to operations that have previously been 
declared without them.) 

The attribute assoc-op-attr is written ‘‘assoe\ It asserts the assoeiativity 
of an operation /: 

=f{f{x,y),z) 

The attribute of associativity moreover implies a local parsing annotation (see 

Sect. 11:5.2.3) that allows an inhx operation / of the form ‘ t ’ (or ‘ ’) 

to be iterated without explicit grouping parentheses. 

The attribute comm-op-attr is written ^eomm\ It asserts the eommuta- 
tivity of an operation /: 

f(x,y) =f{y,x) 

The attribute idem-op-attr is written Adem\ It asserts the idempoteney of 
an operation /: 

f{x,x) = X 

The attribute UNIT-OP-ATTR is written ^unit T\ It asserts that the value of 
the term T is the unit (left and right) of an operation /: 

f{T,x) = x ^ f(x, T) = x 

In practice, the unit T is normally a constant. In any case, T must not contain 
any free variables (i.e., variables that are not explicitly declared by enclosing 
quantihcations). 

The declaration enclosing an operation attribute is ill-formed unless the 
operation prohle has exactly two argument sorts, both the same, which, except 
in the case of commutativity, have also to be the same as the result sort. 
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Operation Definitions 

OP-DEFN ::= op-defn OP-NAME OP-HEAD TERM 

OP-HEAD ::= TOTAL-OP-HEAD | PARTIAL-OP-HEAD 

TOTAL-OP-HEAD : := total-op-head ARG-DECL* SORT 

PARTIAL-OP-HEAD : := partial -op -he ad ARG-DECL* SORT 

ARG-DECL ::= arg-decl VAR+ SORT 

A definition OP-DEFN of a total operation with some arguments is written: 

5 • • • 5 5 • • • 5 '^nl 5 • • • 5 '^nirin ' ^n) ' S — T 

When the list of arguments is empty, the definition is simply written: 
f:s=T 

A definition OP-DEFN of a partial operation with some arguments is written: 

5 • • • 5 5 • • • 5 '^nl 5 • • • 5 '^nmn • 5 = T 

When the list of arguments is empty, the definition is simply written: 
f:ls=T 

It declares the operation name / as a total, respectively partial operation, 
with a profile having argument sorts si (mi times), . . . , Sn (m^ times) and 
result sort s. It also asserts the strong equation: 

5 • • • 5 '^nmn ) ~ ^ 

universally quantified over the declared argument variables (which must be 
distinct, and are the only free variables allowed in T), or just ‘/ = T’ when 
the list of arguments is empty. 

In each of the above cases, the operation name / may occur in the term 
T, and may have any interpretation satisfying the equation - not necessarily 
the least fixed point. 

2.3.3 Predicates 

PRED-ITEMS ::= pred-items PRED-ITEM+ 

PRED-ITEM ::=PRED-DECL | PRED-DEFN 
PRED-NAME ::= ID 

A list PRED-ITEMS of predicate declarations and definitions is written: 
preds P/i; ... P4; 

Predicate Declarations 

PRED-DECL ::= pred-deci PRED-NAME+ PRED-TYPE 
A predicate declaration PRED-DECL is written: 

Pi, . . . : TY 

It declares each predicate name pi, ..., p^ as a predicate, with profile as 
specified by the predicate type TY . 
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Predicate Types 

PRED-TYPE ::= pred-type SORT-LIST 

A predicate type PRED-TYPE with some argument sorts is written: 

Si X ... X Sn 

The sign displayed as ‘x’ may be input as ‘x’ in ISO Latin- 1, or as in 
ASCII. When the list of argument sorts is empty, the type is written 

The predicate prohle determined by the type has argument sorts 5i, . . . , 5^. 

Predicate Definitions 

PRED-DEFN : := pred-defn PRED-NAME PRED-HEAD FORMULA 
PRED-HEAD : := pred-head ARG-DECL* 

A dehnition PRED-DEFN of a predicate with some arguments is written: 

p('^ll5 • • • 5 • • • 5 '^nl 5 • • • 5 '^nirin • 

When the list of arguments is empty, the dehnition is simply written: 

p F 

The sign displayed as is input as ‘<=>’. 

It declares the predicate name p as a predicate, with a prohle having argu- 
ment sorts Si {mi times), . . . , Sn times). It also asserts the equivalence: 

p('^ll5 • • • 5 ^ ^ 

universally quantihed over the declared argument variables (which must be 
distinct, and are the only free variables allowed in F), or just ‘p F’ when 
the list of arguments is empty. The predicate name p may occur in the formula 
F, and may have any interpretation satisfying the equivalence. 



2.3.4 Datatypes 

DATATYPE- ITEMS : := datatype -items DATATYPE-DECL+ 

A list DATATYPE- ITEMS of datatype declarations is written: 
types DDi; . . . DDn] 

The order of the datatype declarations is not signihcant: there is non-linear 
visibility of the declared sorts in a list (in contrast to the linear visibility 
between the BASIC- ITEMS of a BASIC-SPEC, and between the SIG- ITEMS of a 
SORT-GEN). 
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Datatype Declarations 

DATATYPE-DECL : := datatype-decl SORT ALTERNATIVE+ 

A datatype declaration DATATYPE-DECL is written: 
s ::= Ai I . . . I An 

It declares the sort s. For each alternative construct Ai, . . . , it declares 
the specihed constructor and selector operations, and determines sentences as- 
serting the expected relationship between selectors and constructors. All sorts 
used in an alternative construct must be declared in the local environment 
(which always includes the sort declared by the datatype declaration itself). 
A list of datatype declarations must not declare a function symbol both as a 
constructor and selector with the same prohles. 

Note that a datatype declaration allows models where the ranges of the 
constructors are not disjoint, and where not all values are the results of con- 
structors. This looseness can be eliminated in a general way by use of free 
extensions in structured specihcations (as summarized in Chap. 4), or by use 
of free datatypes within basic specihcations (see below). Unreachable values 
can be eliminated also by the use of sort generation constraints. 

Alternatives 

ALTERNATIVE ::= TOTAL- CONSTRUCT | PARTIAL-CONSTRUCT 

TOTAL-CONSTRUCT ::= total-construct OP-NAME COMPONENTS* 
PARTIAL-CONSTRUCT ::= partial- construct OP-NAME C0MP0NENTS+ 

A total constructor TOTAL-CONSTRUCT with some components is written: 

/(O; C'„) 

When the list of components is empty, the constructor is simply written ‘/’. 

A partial constructor PARTIAL-CONSTRUCT with some components is writ- 
ten: 

/(O; C„)? 

(Partial constructors without components are not expressible in datatype dec- 
larations.) 

The alternative declares / as an operation. Each component (7i , . . . , Cn 
specihes one or more argument sorts for the prohle, and possibly some com- 
ponent selectors; the result sort is the sort declared by the enclosing datatype 
declaration. The selectors within each alternative must be distinct, but need 
not be distinct from selectors in different alternatives. 
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Components 

COMPONENTS ::= TOTAL- SELECT | PARTIAL- SELECT | SORT 
TOTAL-SELECT ::= total-select 0P-NAME+ SORT 

PARTIAL-SELECT ::= partial-select 0P-NAME+ SORT 

A declaration TOTAL -SELECT of total selectors is written: 

■■ S 

A declaration PARTIAL -SELECT of partial selectors is written: 

:? s 

The remaining case is a component sort without any selector, simply written 

In the hrst two cases, the component declaration provides n components: 
the sort s is taken as an argument sort n times for the constructor operation 
declared by the enclosing alternative, and it declares /i, . . . ^ fn as selector 
operations for the respective components. In the hrst case, each selector oper- 
ation is declared as total, and in the second case, as partial. The component 
declaration also determines sentences that dehne the value of each selector on 
the values given by the constructor of the enclosing alternative. 

In the last case, the component declaration provides the sort s only once 
as an argument sort for the constructor of the enclosing alternative, and it 
does not declare any selector operation for that component. 

Note that when there is more than one alternative construct in a datatype 
declaration, selectors are usually partial, and should therefore be declared as 
such; their values on constructs for which they are not declared as selectors 
are left unspecihed. 

Free Datatype Declarations 

FREE-DATATYPE : := f ree-datatype DATATYPE -I TENS 
A list FREE-DATATYPE of free datatype declarations is written: 
free types DDi; . . . DD^] 

This construct is only well-formed when all the constructors declared by the 
datatype declarations are total. 

Free datatype declarations declare the same sorts, constructors, and selec- 
tors as ordinary datatype declarations. Apart from the sentences that dehne 
the values of selectors, the free datatype declarations determine additional 
sentences requiring that the constructors are injective, that the ranges of con- 
structors of the same sort are disjoint, that all the declared sorts are generated 
by the constructors, and that the value of applying a selector to a constructor 
for which it has not been declared is always undehned. The sentences ensure 
that the models, if any, are the same as for a free extension with the datatype 
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declarations, provided that the following conditions are fulhlled (all conditions 
refer to fully qualihed symbols): 

• all the declared sorts are distinct from those in the local environment, and 

• each total selector is present in all the alternatives for its argument sort. 

When the alternatives of a free datatype declaration are all constants, the 
declared sort corresponds to an (unordered) enumeration type. 



2.3.5 Sort Generation 

SORT-GEN ::= sort-gen SIG-ITEMS+ 

A sort generation SORT-GEN is written: 
generated { SIi . . . Sin } ; 

When the list of SIG- ITEMS is a single DATATYPE- ITEMS construct, writing 
the grouping signs is optional: 

generated types DDi] . . . DDn'-> 

(The terminating is optional in both cases.) 

It determines the same elements of signature and sentences as SI \ , . . . , 
Sln^ together with a corresponding sort generation constraint sentence: all the 
declared sorts of SIi , . . . , Sin are required to be generated by the declared 
operations of SI \ , . . . , Sin ~ but excluding operations declared as selectors 
by datatype declarations. A SORT- GEN is ill- formed if it does not declare any 
sorts. 



2.4 Variables 

Variables for use in terms may be declared globally, locally, or with explicit 
quantihcation. Globally or locally declared variables are implicitly universally 
quantihed in subsequent axioms of the enclosing basic specihcation. Variables 
are not included in the declared signature. 

Universal quantihcation over a variable that does not occur free in an 
axiom is semantically irrelevant, due to the assumption that all carrier sets 
are non-empty. 



2.4.1 Global Variable Declarations 

VAR-ITEMS ::= var-items VAR-DECL+ 

A list VAR-ITEMS of variable declarations is written: 
vars VDi ; . . . VDn ; 
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Note that local variable declarations are written in a similar way, but followed 
directly by a bullet ‘ • ’ instead of the optional semicolon. 

VAR-DECL ::= var-decl VAR+ SORT 
VAR ::= SIMPLE-ID 

A variable declaration VAR-DECL is written: 

Vi,...,Vn : S 

It declares the variables vi^ ^ Vn of sort s for use in subsequent axioms, but 
it does not contribute to the declared signature. 

The scope of a global variable declaration is the subsequent axioms of the 
enclosing basic specihcation; a later declaration for a variable with the same 
identiher overrides the earlier declaration (regardless of whether the sorts of 
the variables are the same). A global declaration of a variable is equivalent to 
adding a universal quantihcation on that variable to the subsequent axioms 
of the enclosing basic specihcation. 



2.4.2 Local Variable Declarations 

LOCAL-VAR- AXIOMS : := local-var-axioms VAR-DECL+ AXI0M+ 

A localization LOCAL-VAR-AXIOMS of variable declarations to a list of axioms 
is written: 

vm; VDn • Fi... . 

The sign displayed as ‘V’ is input as ‘for all’. The sign displayed as ‘ ’ may 

be input as in ISO Latin- 1, or as ‘ ’ in ASCII. 

It declares variables for local use in the axioms Fi, . . . , F^, but it does 
not contribute to the declared signature. A local declaration of a variable 
is equivalent to adding a universal quantihcation on that variable to all the 
indicated axioms. 



2.5 Axioms 

AXIOM-ITEMS ::= axiom-items AXI0M+ 

AXIOM ::= FORMULA 

A list AXIOM- ITEMS of axioms is written: 

• Fi . . . • Fn 

Each well-formed axiom determines a sentence of the underlying basic speci- 
hcation (closed by universal quantihcation over all declared variables). 
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FORMULA ::= QUANTIFICATION | CONJUNCTION | DISJUNCTION 
I IMPLICATION I EQUIVALENCE | NEGATION | ATOM 

A formula is constructed from atomic formulas of the form ATOM using quan- 
tification and the usual logical connectives. 

Keywords in formulas and terms are displayed in the same font as identi- 
fiers. 



2.5.1 Quantifications 

QUANTIFICATION ::= quantification QUANTIFIER VAR-DECL+ FORMULA 
QUANTIFIER ::= universal | existential | unique-existential 

A quantification with the universal quantifier is written: 

Vrai; VDn • F 

The sign displayed as ‘V’ is input as ‘for all’. The sign displayed as ‘ ’ may 

be input as in ISO Latin-1, or as ‘ ’ in ASCII. 

A quantification with the existential quantifier is written: 

3rai; ...; ra, • F 

A quantification with the unique-existential quantifier is written: 

3!rai; ...; VD^ • F 

The sign displayed as ‘3’ is input as ‘exists’. 

The first case is universal quantification, holding when the body F holds 
for all values of the quantified variables; the second case is existential quan- 
tification, holding when the body F holds for some values of the quantified 
variables; and the last case is unique existential quantification, abbreviating a 
formula that holds when the body F holds for unique values of the quantified 
variables. 

The formula V VDi ; . . . ; VD^ • F is equivalent to V VDi • ... V VD^ • 
F; and V'Ci,...,'Cn : s • F is equivalent to \/vi : s • : s • F. 

Similarly for the other quantifiers. The scope of a variable declaration in a 
quantification is the component formula F, and an inner declaration for a 
variable with the same identifier as in an outer declaration overrides the outer 
declaration (regardless of whether the sorts of the variables are the same). 
Note that the body of a quantification extends as far as possible. 

2.5.2 Logical Connectives 

The usual logical connectives are provided. Conjunction and disjunction apply 
to lists of two or more formulas; they both have weaker precedence than 
negation. When mixed, they have to be explicitly grouped, using parentheses 
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Both implication (which may be written in two different ways) and equiv- 
alence have weaker precedence than conjunction and disjunction. When the 
‘forward’ version of implication is iterated, it is implicitly grouped to the 
right; the ‘backward’ version is grouped to the left. When these constructs 
are mixed, they have to be explicitly grouped. 

Conjunction 

CONJUNCTION ::= conjunction F0RMULA+ 

A conjunction is written: 

Fi A . . . A 

The sign displayed as ‘A’ is input as ‘/\’. 

Disjunction 

DISJUNCTION ::= disjunction F0RMULA+ 

A disjunction is written: 

Fi V . . . V 

The sign displayed as ‘V’ is input as ‘\/’. 

Implication 

IMPLICATION ::= implication FORMULA FORMULA 
An implication is written: 

Fi ^ F2 

The sign displayed as ‘^’ is input as ‘=>’. An implication may also be written 
in reverse order: 

F2 if F I 

Equivalence 

EQUIVALENCE : : = equivalence FORMULA FORMULA 
An equivalence is written: 

Fi F2 

The sign displayed as ‘<t^’ is input as ‘<=>’. 
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Negation 

NEGATION ::= negation FORMULA 
A negation is written: 

-^Fi 

The sign displayed as may be input as in ISO Latin- 1, or as ‘not’ in 
ASCII. 



2.5.3 Atomic Formulas 

ATOM ::= TRUTH | PREDICATION | DEFINEDNESS 
I EXISTL-EQUATION | STRONG-EQUATION 

An atomic formula ATOM is well-formed (with respect to the local environment 
and variable declarations) if it is well-sorted and expands to a unique atomic 
formula for constructing sentences. The notions of when an atomic formula 
is well-sorted^ of when a term is well-sorted for a particular sort^ and of the 
expansions of atomic formulas and terms, are indicated below for the various 
constructs. 

Due to overloading of predicate and/or operation symbols, a well-sorted 
atomic formula or term may have several expansions, preventing it from being 
well-formed. Qualihcations on operation and predicate symbols may be used 
to determine the intended expansion and make it well- formed; explicit sorts 
on arguments and/or results may also help to avoid unintended expansions. 

Truth 

TRUTH ::= true-atom | false-atom 

The atomic formulas true-atom and false-atom are written Hrue\ resp. 
‘‘false\ 

They are always well-sorted, and expand to primitive sentences, such that 
the sentence for Hrue^ always holds, and the sentence for ^false^ never holds. 



Predicate Application 

PREDICATION ::= predication PRED-SYMB TERMS 

PRED-SYMB ::=PRED-NAME | QUAL-PRED-NAME 

QUAL-PRED-NAME ::= qual-pred-name PRED-NAME PRED-TYPE 

An application of a predicate symbol PS to some argument terms is written: 
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When PS is a mixfix identifier (cf. Sect. 2.6) consisting of a sequence 

% ... tn of possibly-empty mixfix tokens ti separated by place-holders 

‘ the application may also be written: 

toTi... Tntn 

When the predicate symbol is a constant p with no argument terms, its ap- 
plication is simply written ‘p’. 

A qualihed predicate name QUAL-PRED-NAME with type TY is written: 
{pred p : TY) 

An unqualihed predicate name PRED -NAME is simply written ‘p’. 

The application of the predicate symbol is well-sorted when there is a 
declaration of the predicate name (with the argument sorts indicated by the 
indicated type in the case of a qualihed predicate name) such that all the 
argument terms are well-sorted for the respective argument sorts. It then 
expands to an application of the qualihed predicate name to the fully-qualihed 
expansions of the argument terms for those sorts. 

Definedness 

DEFINEDNESS ::= definedness TERM 
A dehnedness formula is written: 
defT 

It is well-sorted when the term is well- sorted for some sort. It then expands 
to a dehnedness assertion on the fully-qualihed expansion of the term. 

Equations 

EXISTL-EQUATION ::= existl-equation TERM TERM 
STRONG-EQUATION : := strong-equation TERM TERM 

An existential equation EXISTL-EQUATION is written: 

Ti = T2 

The sign displayed as ‘=’ is input as ‘=e=’. 

A strong equation is written: 

Ti= T2 

An existential equation holds when the values of the terms are both dehned 
and equal; a strong equation holds also when the values of both terms are 
undehned (thus the two forms of equation are equivalent when the values of 
both terms are always dehned). 

An equation is well-sorted if there is a sort such that both terms are well- 
sorted for that sort. It then expands to the corresponding existential or strong 
equation on the fully-qualihed expansions of the terms for that sort. 
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2.5.4 Terms 

TERM ::= SIMPLE-ID | QUAL-VAR | APPLICATION 
I SORTED-TERM | CONDITIONAL 

A term is constructed from constants and variables by applications of oper- 
ations. All names used in terms may be qualified by the intended types, and 
the intended sort of the term may be specified. Note that the condition of a 
conditional term is a formula, not a term. 



Identifiers 

An unqualified simple identifier in a term may be a variable or a constant, 
depending on the local environment and the variable declarations. Either is 
well-sorted for the sort specified in its declaration; a variable expands to the 
(sorted) variable itself, whereas a constant expands to an application of the 
qualified symbol to the empty list of arguments. Note that when an identifier 
is declared both as variable and as a constant of the same sort, unqualified 
use of the identifier always makes the enclosing atomic formula ill-formed. 



Qualified Variables 

QUAL-VAR ::= qual-var VAR SORT 
A qualified variable QUAL-VAR is written: 

{var V : s) 

It is well-sorted for the sort s if v has been declared accordingly. 



Operation Application 



APPLICATION 

OP-SYMB 

QUAL-OP-NAME 

TERMS 



= application OP-SYMB TERMS 
= OP-NAME I QUAL-OP-NAME 
= qual-op-name OP-NAME OP-TYPE 
= terms TERM* 



An application of an operation symbol OS to some argument terms is written: 



When OS is a mixfix identifier (cf. Sect. 2.6) consisting of a sequence 

Ho ... tn of possibly-empty mixfix tokens ti separated by place-holders 

‘ ’, the application may also be written: 



toTi... Tntn 
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When the operation symbol is a constant c with no argument terms, its ap- 
plication is simply written ‘c’. 

Declaring different mixhx identihers that involve some common tokens 
may lead to ambiguity, with different candidate groupings of the same se- 
quence of tokens and terms. Such ambiguity prevents the enclosing atomic 
formula from being well- formed, irrespective of the declared prohles of the 
symbols involved, and generally has to be eliminated by use of explicit group- 
ing parentheses. However, to allow the omission of some parentheses, inhx 
identihers are given weaker precedence than prehx identihers, which in turn 
are given weaker precedence than posthx identihers. (The mixhx identiher 

‘ ’ is allowed, and regarded as an inhx, although this is unlikely to be 

the case in higher-order extensions of Casl, since there juxtaposition will be 
reserved for function application.) 

fn an application, a qualihed operation name QUAL- OP-NAME with / qual- 
ihed by the operation type TY is written: 

(op f : TY) 

When the qualihed operation name is a constant c, its application (to no 
arguments) is written {op c : TY). 

The application is well-sorted for some particular sort when there is a dec- 
laration of the operation name (with the argument and result sorts indicated 
by the type, if specihed) such that all the argument terms are well-sorted for 
the respective argument sorts, and the result sort is the required sort, ft then 
expands to an application of the qualihed operation name to the fully-qualihed 
expansions of the argument terms for those sorts. 



Sorted Terms 

SORTED-TERM : := sorted-term TERM SORT 
A sorted term is written: 

T : 5 

ft is well-sorted for some sort if the component term T is well-sorted for the 
specihed sort s. ft then expands to those of the fully-qualihed expansions of 
the component term that have the specihed sort. 



Conditional Terms 

CONDITIONAL : := conditional TERM FORMULA TERM 
A conditional term is written: 

Ti when F else T 2 
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It is well-sorted for some sort when both Ti and T 2 are well-sorted for 
that sort and F is a well-formed formula. The enclosing atomic formula 
‘T[Ti when F else T 2 ]’ expands to ^{A[Ti] if F) A (^[^ 2 ] if ^F)\ When 
several conditional terms occur in the same atomic formula, the expansions 
are made in a hxed but arbitrary order (all orders yield equivalent formulas). 



2.6 Identifiers 

SIMPLE- ID : := WORDS 
SORT- ID ::= WORDS 
ID : : = id TOKEN 

The internal structure of identihers, used to identify sorts, operations, pred- 
icates, and variables, is insignihcant in the abstract syntax of basic speci- 
hcations. (SORT- ID and ID are extended with compound identihers, whose 
structure is signihcant, in connection with generic specihcations in Sect. 4.6.) 

TOKEN ::= WORDS I DOT-WORDS I SIGNS I DIGIT | QUOTED-CHAR 

In concrete syntax, an identiher may be written as a single token: either a 
sequence of words - each consisting of letters, digits, and primes (’), the hrst 
word starting with a letter) separated by single underscores (_) and possibly 
prehxed by a dot (.) - or a sequence of other printable ISO Latin-1 char- 
acters (excluding ( ) ; , ‘ " %). Keywords, and various other sequences 
that could be confused with separators, are not allowed as tokens in the in- 
put syntax (however, display annotations may be used to produce them when 
formatting identihers, cf. Sect. 11:5.2.2). 

ID : := id MIX-T0KEN+ 

MIX-TOKEN ::= TOKEN | PLACE | BRACED-ID | BRACKET-ID | EMPTY-BRS 

BRACED- ID : := braced- id ID 

BRACKET-ID: := bracket-id ID 

EMPTY-BRS : := empty-braces | empty-brackets 

An identiher may also be a mixfix identifier"^ Hq ... tn\ consisting of a 

sequence of possibly-empty mixhx tokens U interspersed with place-holders^ 
each place-holder being written as a pair of underscores ‘ Mixhx identi- 

hers allow the use of mixfix notation for application of operations and predi- 
cates to argument terms in concrete syntax. A mixhx identiher such as f is 

a different symbol from f . An application of the (unqualihed) symbol / to 

X may be written as f x, f (x) , or f (x) ; an application of / to x may only 

be written as f (x) . ‘Invisible’ identihers, consisting entirely of two or more 
place-holders (separated by spaces), are allowed. 

Mixhx notation is so-called because it generalizes inhx, prehx, and posthx nota- 
tion to allow arbitrary mixing of argument positions and identiher tokens. 
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Braces and square brackets ‘ [’, d ’ are allowed as mixfix tokens in 

mixfix identifiers; however, any occurrences of these characters in a declared 
identiher must be balanced - e.g., [ }] ’ and ] ’ are not allowed. 

An identiher may be used simultaneously to identify different kinds of 
entities (sorts, operations, and predicates) in the same local environment; its 
intended interpretation is determined by the context. 
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Subsorting Specifications 



Section 3.1 introduces the signatures, models, and sentences characterizing ba- 
sic specihcations with subsorts, extending what was provided for many-sorted 
specihcations in Chap. 2. The notion of satisfaction for subsorted specihca- 
tions is essentially as for many-sorted specihcations. The rest of the chapter 
indicates the abstract and concrete syntax of the constructs of subsorted basic 
specihcations, and describes their intended interpretation, extending Chap. 2. 
Section 3.2 covers the declaration and dehnition of subsorts, and Sect. 3.3 
introduces subsort membership tests and casts for use in axioms. 



3.1 Subsorting Concepts 

The intuition behind the treatment of subsorts adopted here is to represent 
subsort inclusion by embedding (which is not required to be the identity), 
commuting, as usual in order-sorted approaches, with overloaded operation 
symbols. In the language described later in this chapter, however, no condi- 
tions such as ‘regularity’ are imposed on signatures. Instead, terms and sen- 
tences that can be given different parses (up to the commutativity between 
embedding and overloaded symbols) are simply rejected as ill-formed. 

3.1.1 Signatures 

A subsorted signature U = (5, TF, PF ^ P, <) consists of a many-sorted signa- 
ture (P, TF ^ PF ^ P) together with a pre-order < of subsort embedding on the 
set S of sorts. The pre-order < is extended pointwise to sequences of sorts. 

For a subsorted signature, we dehne overloading relations for operation and 
predicate symbols. Two qualihed operation symbols fwi,si and fw 2 ,s 2 are in the 
overloading relation (written fwi,si fw2,s2) iff there exists a re G P* and 
5 G P such that w < wi,W 2 and 5i,52 < s. Similarly, two qualihed predicate 
symbols and p ^2 are in the overloading relation (written p^^ ~ p ) iff 
there exists a re G P* such that re < rei , re 2 . We say that two prohles of a 
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symbol are in the overloading relation if the corresponding qualihed symbols 
are in the overloading relation. 

Note that two prohles of an overloaded constant declared with different 
sorts are in the overloading relation iff the two sorts have a common supersort. 

A subsorted signature morphism a : A ^ A' is a many-sorted signature 
morphism that preserves the subsort relation and the overloading relations. 

With each subsorted signature E = (/S', TF, PF^P^ <) a many-sorted sig- 
nature is associated, extending (S', TF, FF, F) for each pair of sorts s < s' 
by a total embedding operation (from s into 5 '), a partial projection operation 
(from s' onto 5 ), and a membership predicate (testing whether values in s' are 
embeddings of values in s). The symbols used for embedding, projection, and 
membership are chosen to be distinct from all symbols that can be explicitly 
declared in specihcations. 

Any subsorted signature morphism a : Ei ^ E 2 expands to a many- 
sorted signature morphism : E^ E^ ^ preserving the symbols used for 
embedding, projection, and membership. 



3.1.2 Models 

For a subsorted signature E the subsorted models are ordinary many-sorted 

models for E^ that satisfy the following properties (which can be formalized 

as a set of conditional axioms): 

• Embedding operations are total and injective; projection operations are 
partial, and injective when dehned. 

• The embedding of a sort into itself is the identity function. 

• All compositions of embedding operations between the same two sorts are 
equal functions. 

• Embedding followed by projection is the identity function; projection fol- 
lowed by embedding is included in the identity function. 

• Membership in a subsort holds just when the projection to the subsort is 
dehned. 

• Embedding is compatible with those operations and predicates that are in 
the overloading relations. 



3.1.3 Sentences 

For a subsorted signature A, the subsorted sentenees are the ordinary many- 
sorted sentences (as dehned in Chap. 2) for the associated many-sorted sig- 
nature E^ . 

A well- formed subsorted basic specihcation BASIC -SPEC of the Casl lan- 
guage determines a basic specihcation of the underlying subsorted institution, 
consisting of a subsorted signature and a set of sentences of the form described 
above. This signature and the class of models over it that satisfy the set of 
sentences provide the semantics of the basic specihcation. 
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3.2 Signature Declarations 

No further alternatives for SIG- ITEMS are needed. 



3.2.1 Sorts 

SORT-ITEM ::= ... | SUBSORT-DECL | ISO-DECL | SUBSORT-DEFN 

When a subsort declaration SUBSORT-DECL, isomorphism declaration ISO- 
DECL, or subsort dehnition SUBSORT-DEFN occurs in a sort generation con- 
struct, the embedding operations between the subsort (s) and the supersort 
are treated as declared operations with regard to the generation of sorts and 
to free datatype declarations. 



Subsort Declarations 

SUBSORT-DECL : := subsort-decl S0RT+ SORT 
A subsort declaration SUBSORT-DECL is written: 

It declares all the sorts 5i, . . . , 5^, and 5, as well as the embedding of each Si 
as a subsort of s. The Si must be distinct from s. 

Introducing an embedding relation between two sorts may cause operation 
symbols to become related by the overloading relation, so that values of terms 
become equated when the terms are identical up to embedding. 

Isomorphism Declarations 

ISO-DECL : := iso-decl S0RT+ 

An isomorphism declaration ISO-DECL is written: 

Si = . . . = Sn 

It declares all the sorts 5i, . . . , 5^, as well as their embeddings as subsorts of 
each other. Thus the carriers for the sorts Si are required to be isomorphic. 
The Si must be distinct. 



Subsort Definitions 

SUBSORT-DEFN : := subsort-defn SORT VAR SORT FORMULA 
A subsort dehnition SUBSORT-DEFN is written: 



s = {v : s' • F} 
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The sign displayed as ‘ ’ may be input as in ISO Latin-1, or as L’ in 

ASCII. It provides an explicit specification of the values of the subsort 5 of 5 ', 
in contrast to the implicit specihcation provided by using subsort declarations 
and overloaded operation symbols. 

The subsort dehnition declares the sort 5; it declares the embedding of s 
as a subsort of 5 ', which must already be declared in the local environment; 
and it asserts that the values of s are precisely (the projection of) those values 
of the variable v from s' for which the formula F holds. 

The scope of the variable v is restricted to the formula F. Any other vari- 
ables occurring in F must be explicitly declared by enclosing quant ideations. 

Note that the terms of sort s' cannot generally be used as terms of sort s. 
But they can be explicitly projected to 5 , using a cast, cf. Sect. 3.3.2. 

Defined subsorts may be separately related using subsort (or isomorphism) 
declarations - implication or equivalence between their defining formulas does 
not give rise to any subsort relationship between them. 

3.2.2 Datatypes 

Datatype declarations are unchanged, except for a new kind of ALTERNATIVE: 
Alternatives 

ALTERNATIVE : : = ... | SUBSORTS 
SUBSORTS ::= subsorts S0RT+ 

A subsorts alternative is written: 

sorts 5i , . . . , 5^ 

As with sort declarations, the plural keyword may be written in the singular 
(regardless of the number of sorts). 

The sorts 5 ^, which must be already declared in the local environment, 
are declared to be embedded as subsorts of the sort declared by the enclos- 
ing datatype declaration. sorts 5i, . . . , 5^’ and ^sort 5i | ... | sort s^ are 

equivalent.) 

When each alternative of a free datatype declaration is a subsorts alter- 
native, the declared sort corresponds to the disjoint union of the listed sorts, 
provided that these have no common subsorts. The models of a free datatype 
declaration, if any, are the same as for a free extension with the datatype 
declarations, provided that the following conditions are fulhlled (apart from 
those listed concerning free datatype declarations in Sect. 2.3.4): 

• all the sorts that are embedded in the declared sort by the alternatives 
have no common subsorts; and moreover, 

• consider the set of qualihed constructor and selector symbols declared by 
the free datatype: no element of this set is in the overloading relation with 
any other element, nor with the qualihed operation symbols from the local 
environment. 
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3.3 Axioms 

The only further new constructs introduced in connection with subsorts are 
atomic formulas for subsort membership, and terms for casting to subsorts. 



3.3.1 Atomic Formulas 
ATOM : : = ... | MEMBERSHIP 

As for many-sorted specihcations, an atomic formula is well-formed (with re- 
spect to the current declarations) if it is well-sorted and expands to a unique 
atomic formula for constructing sentences of the underlying institution - but 
now for subsorted specihcations, uniqueness is required only up to an equiva- 
lence on atomic formulas and terms. This equivalence is the least one including 
fully-qualihed terms that are the same up to prohles of operation symbols in 
the overloading relation and embedding, and fully-qualihed atomic formu- 
las that are the same up to the prohles of predicate symbols in the overloading 
relation and embedding. 

The notions of when an atomic formula or term is well-sorted and of its 
expansion are indicated below for the various subsorting constructs. Due not 
only to overloading of predicate and/or operation symbols, but also to implicit 
embeddings from subsorts into supersorts, a well-sorted atomic formula may 
have several non-equivalent expansions, preventing it from being well-formed. 
Qualihcations on operation and predicate symbols, or explicit sorts on terms, 
may be used to determine the intended expansion (up to the equivalence 
indicated above) and make the enclosing formula well-formed. 



Membership 

MEMBERSHIP : : = membership TERM SORT 
A membership formula is written: 

T e s 

The sign displayed as ‘g’ is input as ‘in’. 

It is well-sorted if the term T is well- sorted for a supersort s' of the speci- 
hed sort s. It expands to an application of the pre-declared predicate symbol 
for testing s' values for membership in the embedding of s. 
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3.3.2 Terms 
TERM : : = ... | CAST 



Casts 

CAST : : = cast TERM SORT 
A cast term is written: 

T as s 

It is well-sorted if the term T is well-sorted for a supersort 5' of 5 . It expands 
to an application of the pre-declared operation symbol for projecting s' to s. 

Term formation is also extended by letting a well-sorted term of a subsort 
s be regarded as a well-sorted term of a supersort s' as well, which provides 
implicit embedding. It expands to the explicit application of the pre-declared 
operation symbol for embedding s into s'. (There are no implicit projections.) 
Also a sorted-term T : s' expands to an explicit application of an embedding, 
provided that the apparent sort s of the component term T is a subsort of 
the specihed sort s' . 
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Section 4.1 reviews the concepts underlying the structuring constructs pro- 
vided by Casl. The rest of the chapter indicates their abstract and concrete 
syntax, and describes their intended interpretation, extending what was pro- 
vided for basic (many-sorted and subsorted) specihcations in the preceding 
chapters. Section 4.2 covers structured specihcations: renaming, hiding, union, 
extension, and free extension. Section 4.3 introduces named and generic spec- 
ihcations. Section 4.4 indicates how to dehne and use views, with Sect. 4.5 
addressing the use of symbol lists and mappings in connection with views. 
Finally, Sect. 4.6 introduces compound identihers. 



4.1 Structuring Concepts 

Recall that a basic specihcation, as described in Chaps. 2 and 3, consists 
essentially of a signature U (declaring symbols) and a set of sentences (axioms 
or constraints) over U. The semantics of a well- formed basic specihcation is 
the specihed signature U together with the class of all i7-models that satisfy 
the specihed sentences. 

Section 4.1.1 considers structured specihcations, which allow basic spec- 
ihcations to be divided into parts, and the relationship between them to be 
exhibited. Section 4.1.2 is concerned with named specihcations, which allow 
reuse of such parts; generic specihcations have also parameters that can be 
htted to argument specihcations by so-called views - which can themselves be 
named and generic. Section 4.1.3 explains how the signature and specihcation 
morphisms that are involved in structuring are determined by symbol sets 
and mappings. 

4.1.1 Structured Specifications 

A structured specification is formed by combining specihcations in various 
ways, starting from basic specihcations. For instance, specihcations may be 
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united'^ a specification may be extended with further signature items and/or 
sentences; parts of a signature may be hidden'^ the signature may be translated 
to use different symbols (with corresponding translation of the sentences) by a 
signature morphism; and models may be restricted to free extensions {initial 
models are a special case of free extensions). The abstract syntax of constructs 
in the Casl language for presenting such structured specihcations is described 
later in this chapter. 

The structuring concepts and constructs and their semantics do not de- 
pend on a specihc framework of basic specihcations. This means that the 
Casl language design for basic specihcations is orthogonal to that of struc- 
tured specihcations. Therefore, Casl basic specihcations, as summarized in 
the preceding chapters, can be restricted to sublanguages (cf. Sect. 7.1) or 
extended (cf. Sect. 7.2) in various ways without the need to reconsider or to 
change structured specihcations^. 

The semantics of a well-formed structured specihcation is of the same 
form as that of a basic specihcation: a signature U together with a class of 
i7-models. Thus the structure of a specihcation is not rehected in its models: 
it is used only to present the specihcation in a modular style. (Specihcation 
of the arehiteeture of models in the CoFI framework is addressed in Chap. 5.) 

Within a structured specihcation, the eurrent signature may vary. For 
instance, when two specihcations are united, the signature valid in the one 
is generally different from that valid in the other. The association between 
symbols and their declarations as given by the current signature is called the 
loeal environment. 



4.1.2 Named and Generic Specifications 

Parts of structured specihcations, in contrast to arbitrary parts of basic spec- 
ihcations, are potentially reusable - either verbatim, or with the adjustment 
of some parameters. Specihcations may be named^ so that the reuse of a spec- 
ihcation may be replaced by a referenee to it through its name. (Libraries 
of named specihcations are explained in Chap. 6.) The current association 
between names and the specihcations that they reference is called the global 
environment. Named specihcations are implicitly elosed^ not depending on a 
local environment of declared symbols. A reference to the name of a speci- 
hcation is equivalent to the referenced specihcation itself, provided that the 
closedness is explicitly ensured. 

A named specihcation may declare some parameters^ the union of which 
is extended by a body; it is then called generie. A reference to a generic spec- 
ihcation should instantiate it by providing, for each parameter, an argument 

^ The occasional reference to the subsort and overloading relations in this chapter 
may simply be ignored (or the relations may be replaced by the identity relation) 
when the framework for basic specihcations is restricted so as not to include these 
features. 
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specification together with a fitting morphism from the parameter to the ar- 
gument specihcation. Fitting may also be achieved by (explicit) use of named 
views between the parameter and argument specihcations. The union of the 
arguments, together with the translation of the generic specihcation by an ex- 
pansion of the htting morphism, corresponds to a so-called pushout construc- 
tion - taking into account any explicit imports of the generic specihcation, 
which allow symbols used in the body to be declared also by arguments. 



4.1.3 Signature and Specification Morphisms 

The semantics of structured specihcations involve signature morphisms and 
the corresponding reducts on models. For instance, hiding some symbols in a 
specihcation corresponds to a signature morphism that injects the non-hidden 
symbols into the original signature; the models, after hiding the symbols, are 
the reducts of the original models along this morphism. Translation goes the 
other way: the reducts of models over the translated signature back along the 
morphism give the original models. 

The semantics of views involves also specification morphisms^ which are 
signature morphisms between particular specihcations such that the reduct of 
each model of the target specihcation is a model of the source specihcation. 

Given a signature E with symbols |i7|, symbol sets and symbol mappings 
determine signature morphisms as follows: 

• A subset of the symbols in \E\ determines the inclusion of the smallest 
subsignature of E that contains these symbols. (When an operation or 
predicate symbol is included, all the sorts in its prohle have to be included 
too.) 

It also determines the inclusion of the largest subsignature of E that does 
not contain any of these symbols. (When a sort is not included, no op- 
eration or predicate symbol with that sort in its prohle can be included 
either.) 

• A mapping of symbols in \E\ determines the signature morphism from 
E that extends this mapping with identity maps for all the remaining 
names in \E\. In the case that the signature morphism does not exist, the 
enclosing construct is ill- formed. 

• Given another signature E\ a mapping of symbols in \E\ to symbols in 
I A' I determines the unique signature morphism from E to E^ that extends 
the given mapping, and then is the identity, as far as possible, on common 
names of E and E'. (Mapping an operation or predicate symbol implies 
mapping the sorts in the prohle consistently.) In the case that the signature 
morphism does not exist or is not unique, the enclosing construct is ill- 
formed. 
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4.2 Structured Specifications 

The summary below indicates when structured specihcations are well- formed, 
and how their signatures and classes of models are determined by those of their 
component specihcations. The interpretation is essentially based on model 
classes - a ‘battening’ reduction to sets of sentences is not possible, in general 
(due to the presence of constructs such as hiding and freeness). 

A structured specification can only be well-formed when all its component 
specifications are well-formed. 

SPEC ::= BASIC-SPEC I TRANSLATION | REDUCTION 

I UNION I EXTENSION | FREE-SPEC I LOCAL-SPEC 
I CLOSED-SPEC 

A translation allows the symbols declared by a specification to be renamed; 
it may also be used to require that some symbols have been declared, e.g., 
when referencing a named specification. A reduction allows symbols to be hid- 
den; for convenience, the remaining ‘revealed’ symbols may be simultaneously 
renamed. A union combines specifications such that when the declaration 
of a particular symbol is common to some of the combined specifications, 
its interpretation in a model has to be a common one too - this is called 
the ‘same name, same thing’ principle. An extension may enrich models by 
declaring new symbols and asserting their properties, and/or specialize the 
interpretation of already-declared symbols. A free specification is used to re- 
strict interpretations to free extensions^ with initiality as a special case. A 
local specification is used to specify auxiliary symbols for local use, hiding 
them afterwards. A closed specification ensures that the local environment 
provided to a specification is empty. 

When the above constructs are combined in the same specification, the 
grouping is determined unambiguously by precedence rules: translations and 
reductions have the highest precedence, then come local specifications, then 
unions, and finally extensions have the lowest precedence. (Free specifications 
generally involve explicit grouping, and their relative precedence to the other 
constructs is irrelevant.) A different grouping may always be obtained by use 
of grouping braces: 

A specihcation SPEC may occur in a context (e.g., when it is being named) 
where it is required to be self-contained or closed^ not depending on the local 
environment at all. In that case, it determines a signature and a class of models 
straightforwardly. 

In structured specihcations, however, a specihcation SPEC may also occur 
in a context where it is to extend other specihcations, providing itself only 
part of a signature. Then its interpretation determines an extended signature 
A', given a signature E (the local environment), together with a model class 
over E' (when dehned), given a model class over E. The signature and model 
class for the self-contained case above can be obtained by supplying the empty 
signature and the model class of the empty specihcation, respectively. 
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Translations and reductions in a SPEC are not allowed to affect symbols 
that are already in the local environment that is being extended. The other 
structuring constructs generalize straightforwardly from self-contained speci- 
hcations to extensions. 



4.2.1 Translations 

TRANSLATION ::= translation SPEC RENAMING 
RENAMING ::= renaming SYMB-MAP-ITEMS+ 

A translation is written: 

SP with SM 

Symbol mappings SM are described in Sect. 4.5. 

The symbols mapped by SM must be among those declared by SP. The 
signature U given by SP and the mapping SM then determine a signature 
morphism to a signature A', as explained in Sect. 4.1.3. The morphism must 
not affect the symbols already declared in the local environment, which is 
passed unchanged to SP. 

The class of models of the translation consists exactly of those models over 
U' whose reducts along the morphism are models of SP. 

If a partial operation symbol is renamed into a total one, this is only well- 
formed in the case that the resulting operation symbol is already total due to 
another component of the renaming. 

When the symbol mapping SM is simply a list of identity maps (which may 
be abbreviated to a simple list of symbols) the only effect of the translation on 
the semantics of SP is to require that the symbols listed are indeed included 
in the signature given by SP^ otherwise the translation is not well- formed. 



4.2.2 Reductions 

REDUCTION ::= reduction SPEC RESTRICTION 

RESTRICTION ::= HIDDEN | REVEALED 

HIDDEN ::= hidden SYMB-ITEMS+ 

REVEALED ::= revealed SYMB-MAP-ITEMS+ 

A hiding reduction is written: 

SP hide SL 

A revealing reduction is written: 

SP reveal SM 

Symbol lists SL and symbol mappings SM are described in Sect. 4.5. 

The symbols listed by SL^ or mapped by SM^ must be among those de- 
clared by SP. 
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In the case of a hiding reduction, the signature U given by SP and the set of 
symbols listed by SL determine the inclusion of the largest subsignature of 
U that does not contain any of the listed symbols, as explained in Sect. 4.1.3. 
Note that hiding a sort entails hiding all the operations and predicate symbols 
whose prohles involve that sort. 

In the case of a revealing reduction, the signature U given by SP and 
the set of symbols mapped by SM determine the inclusion of the smallest 
subsignature E' of E that contains all of the listed symbols, as explained 
in Sect. 4.1.3. Note that revealing an operation or predicate symbol entails 
revealing the sorts involved in its prohle. 

In both cases, the subsort embedding relation is inherited from that de- 
clared by iSP, and a model class A4 is given by the reducts of the models of 
SP along the inclusion of E' in E. 

In the case of a hiding reduction, its model class is simply A4. In the case 
of a revealing reduction, however, the signature E' and the mapping SM of 
(all) the symbols in it determine a signature morphism to a signature E'\ 
as explained in Sect. 4.1.3. The class of models of the reduction then consists 
exactly of those models over E" whose reducts along this morphism are in A4. 

A reduction must not affect the symbols already declared in the local 
environment, which is passed unchanged to SP. 



4.2.3 Unions 

UNION : := union SPEC+ 

A union is written: 

SPi and . . . and SPn 

When the current local environment is empty, each SPi must determine a 
complete signature Ei. The signature of the union is obtained by the ordinary 
union of the Ei (not their disjoint union). Thus all (non- localized) occurrences 
of a symbol in the SPi are interpreted uniformly (rather than being regarded 
as homonyms for potentially different entities). This is the ‘same name, same 
thing’ principle. If the same name is declared both as a total and as a par- 
tial operation with the same prohle (in different signatures), the operation 
becomes total in the union. 

The models are those models of the union signature for which the reduct 
along the signature inclusion morphism from SPi is a model of for each 
z = 1, . . . , n. 

When the current local environment is non-empty, each SPi must deter- 
mine an extension from it to a complete signature then the resulting 
signature is determined as above. Similarly, models of the local environment 
are extended to models of the SPi; then the resulting models are determined 
as above. This provides the required partial functions from signatures to sig- 
natures, and from model classes to model classes. 
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4.2.4 Extensions 

EXTENSION : := extension SPEC+ 

An extension is written: 

SPi then . . . then SPn 

When the current local environment is empty, SPi must determine a com- 
plete signature Ui; otherwise, it must determine an extension from the local 
environment to a complete signature Ui. For z = 2, . . . , n each SPi must de- 
termine an extension from to a complete signature Ui. The signature 

determined by the entire extension is then 

Similarly, SPi determines a class of models A4i over Ui. For i = 2, . . . , n 
each SPi determines the class A4i of those models over Ui which satisfy the 
conditions imposed by SPi and whose reducts to are in A4i-i. The class 
of models determined by the entire extension is then A4n- 

An annotation ‘7ocons’ after the occurrence of ‘then’ that precedes SPi 
indicates that the corresponding extension is conservative, i.e., every model 
in Mi -1 is the reduct of some model in Mi. Similarly, an annotation ‘7oniono’ 
indicates that the corresponding extension is monomorphic, i.e., every model 
in Mi -1 is the reduct of a model in Mi which is unique up to isomorphism. An 
annotation ‘7odef ’ indicates that the corresponding extension is dehnitional, 
i.e., every model in Mi-i is the reduct of a unique model in Mi. Finally, an 
annotation ‘7oimplies’ indicates that the corresponding extension just adds 
implied properties, i.e., the model classes Mi-i and Mi are the same (this 
requires that their signatures are equal, too). 

4.2.5 Free Specifications 
FREE-SPEC : := free-spec SPEC 

A free specihcation FREE-SPEC is written: 
free { SP } 

Recall that the specihcation written: 
free types BBi; . . . BB^; 

is parsed as a free datatype declaration construct of a basic specihcation 
(cf. Sect. 2.3.4), but in fact it usually has the same interpretation as the 
free structured specihcation written: 

free { types BBi; . . . BB^; } 

This equivalence holds at least in the framework for basic specihcations sum- 
marized in Chaps. 2 and 3, under some minor restrictions. 

When the current local environment is empty, SP must determine a com- 
plete signature B; otherwise, it must determine an extension from the local 
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environment to a complete signature U. In both cases, U is the signature 
determined by the free specihcation. 

When the current local environment is empty, the free specihcation deter- 
mines the class of initial models of SP; otherwise, it determines the class of 
models that are free extensions for SP of their own reducts to models of the 
current local environment. 

4.2.6 Local Specifications 
LOCAL-SPEC ::= local-spec SPEC SPEC 

A local specihcation LOCAL-SPEC is written: 
local SPi within SP2 
It is equivalent to writing: 

{ SPi then SP 2 } hide SYu • • • , 

where SYi, . . . , SY^ are all the symbols declared by SPi that are not already 
in the current local environment. Thus the symbols SYi, . . . , SYn are only 
for local use in (SPi and) SP2. The hiding must not affect symbols that are 
declared only in SP2 (thus operation or predicate symbols declared in SP2 
should not have sorts declared by SPi in their prohles). 

4.2.7 Closed Specifications 
CLOSED-SPEC ::= closed-spec SPEC 

A closed specihcation CLOSED-SPEC is written: 
closed { SP } 

It determines the same signature and class of models as SP determines in the 
empty local environment, thus ensuring the closedness of SP. 



4.3 Named and Generic Specifications 

Specihcations are named by specihcation dehnitions, and referenced by use of 
the name. A named specihcation may also have some parameters, which have 
to be instantiated when referencing the specihcation. 



4.3.1 Specification Definitions 

SPEC-DEFN ::= spec-defn SPEC-NAME GENERICITY SPEC 

GENERICITY : := genericity PARAMS IMPORTED 

PARAMS : : = params SPEC* 

IMPORTED ::= imported SPEC* 
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A generic specification definition SPEC-DEFN with some parameters and some 
imports is written: 

spec SN [SP,] . . . [SPn] given SP[\ . . . , SP'^^ = 

SP 

end 

When the list of imports SP[\ . . . , SP^ is empty, the dehnition is written: 

spec SN [SPi] . . . [SPn] = 

SP 

end 

When the list of parameters SPi^ SPn is empty, the dehnition merely 
names a specihcation and is simply written: 

spec SN = 

SP 

end 

The terminating ‘end’ keyword is optional. 

It dehnes the name SN to refer to the specihcation that has parameter 
specihcations SPi^ . . . , SPn (if any), import specihcations SP[\ . . . , SP^ (if 
any), and body specihcation SP. This extends the global environment (which 
must not already include a dehnition for SN). 

The well-formedness and semantics of a generic specihcation are essentially 
as for the imports, extended by the union of the parameter specihcations, 
extended by the body: 

{ SP[' and . . . and SP^;^ } then { SPi and . . . and SPn } then SP 

The local environment given to the dehned specihcation is empty, i.e., the 
above specihcation is implicitly closed. The difference between declaring pa- 
rameters and leaving them implicit in an extension is that each parameter 
has to be provided with a htting argument specihcation in all references to 
the specihcation name SN. The declared parameters show just which parts of 
the generic specihcation are intended to vary between different references to 
it. The imports, in contrast, are hxed, and common to the parameters, body, 
and arguments. 

When a declared parameter happens to be merely a specihcation name, it 
always must refer to an existing specihcation dehnition in the global environ- 
ment - it does not declare a local name for an argument specihcation. 

SPEC-NAME ::= SIMPLE-ID 

A specihcation name SPEC-NAME is normally displayed in a Small-Caps font, 
and input in mixed upper and lower case. 
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4.3.2 Specification Instantiation 

SPEC ::= ... I SPEC- INST 

SPEC-INST ::= spec-inst SPEC-NAME FIT-ARG* 

An instantiation SPEC-INST of a generic specification with some fitting argu- 
ment specifications is written 

SN[FA^]. . .[FAn] 

When the list of htting arguments FAi, . . . , FAn is empty, the instantiation is 
merely a reference to the name of a specihcation that has no declared param- 
eters at all, and it is simply written ‘‘SN\ Note that the grouping braces 
normally required when writing free (or closed) specihcations, may always be 
omitted around instantiations. 

The instantiation refers to the specihcation named SN in the global en- 
vironment, providing a htting argument FAi for each declared parameter (in 
the same order). 

FIT-ARG ::= FIT-SPEC 

FIT-SPEC ::= fit-spec SPEC SYMB -MAP -ITEMS* 

A htting argument specihcation FIT- SPEC is written: 

SP[ fit SMi 

When SMi is empty, the htting argument specihcation is simply written SP[. 
Symbol mappings SM are described in Sects. 4.5 and 4.6. 

The signature Fi given by the parameter specihcation SPi^ the signature 
F[ given by the corresponding argument specihcation, and the symbol map- 
ping SMi determine a signature morphism from Fi to A', as explained in 
Sect. 4.1.3. The htting argument is well- formed only when the signature mor- 
phism is dehned, i.e., the htting argument morphism is well-dehned. Note 
that mapping an operation or predicate symbol generally implies non-identity 
mapping of the sorts in the prohle. 

When there is more than one parameter, the separate htting argument 
morphisms have to be compatible^ and their union has to yield a single mor- 
phism from the union of the parameters to the union of the arguments. Thus 
any common parts of declared parameters have to be instantiated in the same 
way, and it is pointless to declare the same parameter twice in a generic 
specihcation. (Generic specihcations that require two similar but independent 
parameters can be expressed by using a translation to distinguish between the 
symbols in the signatures of the two parameters.) 

Each htting argument FAi is regarded as an extension of the union of 
the imports (the current local environment is ignored). The htting argument 
morphism has to be identity on all symbols declared by the imports /S'Pf , 

. . . , SP^ of the generic specihcation, if there are any. Any symbol declared 
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explicitly in the parameter (and not only in the import) must be mapped to 
a symbol declared explicitly in the argument specihcation. 

Let SP' be the extension of the imports by the generic parameters and 
then by the body of the specihcation named SN: 

{ SP[' and . . . and SP!^^ } then { SPi and . . . and SPn } then SP 

Let FM be the morphism yielded by the htting arguments FAi^ . . . , 
extended to a morphism applicable to the signature of SP' as explained in 
Sects. 4.5 and 4.6 (and written as a list of symbol maps). Then the semantics 
of the well-formed instantiation SN[FAi]. . . [FAn] is the same as that of the 
specihcation: 

{ SP' with FM } and SP[ and . . . and SP^ 

where each SP![ is the specihcation of the corresponding htting argument FAi. 
Each model of an argument FAi (these are models of SP^ reduced by the 
signature morphism determined by SMi) is required to be a model of the 
corresponding parameter SPi^ otherwise the instantiation is undehned. The 
instantiation is not well-formed if the result signature is not a pushout of the 
body and argument signatures: if the translated body 

{ SP' with FM } 

and the union of the argument specihcations 
SP[ and . . . and SP^^ 

share any symbols, these symbols have to be translations (along FM) of sym- 
bols that share in the extension of the imports by the parameters 

{ SP[' and . . . and SP^;^ } then { SPi and . . . and SPn } 

Here, two sorts share if they are identical, and two function or predicate 
symbols share if they are in the overloading relation. 



4.4 Views 

Views between specihcations are named by view dehnitions, and referenced 
by use of the name. A named view may also have some parameters, which 
have to be instantiated when referencing the view. 



4.4.1 View Definitions 

VIEW-DEFN ::= view-defn VIEW-NAME GENERICITY VIEW-TYPE SYMB-MAP-ITEMS* 
VIEW-TYPE ::= view-type SPEC SPEC 

A view dehnition VIEW-DEFN with some parameters and some imports is writ- 
ten: 
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view VN [SPi] . . . [SPn] given SP[' , . . . , SP^;^ : SP to SP' = 

SM 

end 

A view definition VIEW-DEFN with some parameters is written: 

view VN [SPi] . . . [SPn] : SP to SP' = 

SM 

end 

When the list of parameters is empty, the view dehnition is simply written: 

view VN : SP to SP' = 

SM 

end 

The terminating ‘end’ keyword is optional. 

It declares the view name VN to have the type of specihcation morphisms 
from SP to SP' ^ parameter specihcations SP\^ . . . , SPn (if any), import spec- 
ihcations SP'{^ . . . , SP'^ (if any), and dehnes it by the symbol mapping SM . 
Symbol mappings SM are described in Sects. 4.5 and 4.6. 

SP gets the empty local environment. The well-formedness conditions for 
SP' are as if SP' were the body of a generic specihcation with parameters SP \ , 
. . . , SPn and import specihcations SP'l^ . . . , SP'^. The view dehnition is well- 
formed only if the signature morphism determined by the symbol mapping 
SM ^ as explained in Sect. 4.1.3, is dehned. The view dehnition extends the 
global environment (which must not already include a dehnition for VN). 

Parameters in a view dehnition allow the same view to be instantiated 
with different htting arguments, giving compositions of the morphism dehned 
by the view with other htting morphisms. The source SP of the view is not in 
the scope of the view parameters SPi^ . . . , SP^ and view instantiation affects 
only the target of the generic view. 

It is required that the reduct by the specihcation morphism of each model 
of the target 

{ SP[' and . . . and SP^ } then { SPi and . . . and SPn } then SP' 

is a model of the source SP; otherwise the semantics is undehned. 

VIEW-NAME ::= SIMPLE-ID 

A view name VIEW-NAME is normally displayed in a Small-Caps font, and 
input in mixed upper and lower case. 



4.4.2 Fitting Views 

FIT-ARG ::= ... I FIT-VIEW 
FIT-VIEW ::= fit-view VIEW-NAME 
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A reference to a non- generic fitting argument view FIT- VIEW is simply written: 

view VN 

It refers to the current global environment, and is well- formed as an argument 
for a parameter SPi only when the global environment includes a view def- 
inition for VN of type from SP to SP' ^ such that the signatures of SP and 
of SPi are the same. The view dehnition then provides the htting morphism 
from the parameter SPi to the argument specihcation given by the target SP' 
of the view. 

If the generic specihcation being instantiated has imports, the htting mor- 
phism is then the union of the specihcation morphism given by the view and 
the identity morphism on the imports. The argument specihcation is the union 
of the target of the view and the imports. 

Each model of SP is required to be a model of SPi^ otherwise the instan- 
tiation is undehned. 

FIT-VIEW ::= ... I fit-view VIEW-NAME FIT-ARG+ 

A htting argument view FIT- VIEW involving the instantiation of a generic 
view to htting arguments is written: 

view VN [FAi]. . .[FAn] 

It refers to the current global environment, and is well- formed only when the 
global environment includes a generic view dehnition for VN with parameters 
that can be instantiated by the indicated htting arguments FTi, . . . , FAn to 
give a view of type from SP to SP' ^ such that the signatures of SP and of SPi 
are the same. As with non-generic views, each model of SP is required to be a 
model of SPi^ otherwise the instantiation is undehned. The instantiation of a 
generic view with some htting arguments is not well-formed if the instantiation 
of the target SP' of the view with the same htting arguments is not well- 
formed. 



4.5 Symbol Lists and Mappings 

Symbol lists are used in hiding reductions. Symbol mappings are used in 
translations, revealing reductions, htting arguments, and views. 



4.5.1 Symbol Lists 



SYMB-ITEMS 

SYMB-KIND 

SYMB 

QUAL-ID 

TYPE 



= symb- items SYMB-KIND SYMB+ 

= implicit I sorts-kind | ops-kind | preds-kind 
= ID I QUAL-ID 
= qual-id ID TYPE 
= OP-TYPE I PRED-TYPE 
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A list of symbols SYMB- ITEMS with implicit kinds SYMB-KIND is written simply: 

SY,,...,SY„ 

Overloaded operation symbols and predicate symbols may be disambiguated 
by explicit qualification; when SYi is not qualihed, the effect is as if all (sort, 
operation, or predicate) symbols declared with the name SYi in the current 
local environment are listed. 

Optionally, the list may be sectioned into sub-lists by inserting the key- 
words ‘sorts’, ‘ops’, ‘preds’ (or their singular forms), which explicitly indi- 
cate that the subsequent symbols are of the corresponding kind: 

sorts 5i , . . . , ops /i , . . . , preds pi , ... 

As with signature declarations in basic specihcations, there is no restriction 
on the order of the various sections of the list. 

A qualihed identiher QUAL-ID is written 

I : TY 

where TY is an operation type or a predicate type. When TY is a single sort 
5, it is interpreted as a constant operation type or unary predicate type, as 
determined by the latest keyword, or, when there is none, unambiguously by 
the local environment. 

The list determines a set of qualihed symbols, obtained from the listed 
symbols with reference to a given signature; the order in which symbols are 
listed is not signihcant (except regarding their position in relation to any 
specihed kinds). 

Note that in the symbol list ‘A , . . . : TT’ it is only the last identiher, 

In^ which is qualihed; to qualify all the identihers, the list has to be written 
thus: 

h:TY , . . . , In.TY 



4.5.2 Symbol Mappings 

SYMB-MAP- ITEMS : := symb-map- items SYMB-KIND SYMB-OR-MAP+ 

SYMB-OR-MAP ::= SYMB | SYMB-MAP 
SYMB-MAP ::= symb-map SYMB SYMB 

A list of symbol maps SYMB-MAP- ITEMS with implicit kinds SYMB-KIND is writ- 
ten simply: 

SYi ^ SY[,...,SYn ^ SYl^ 

The sign displayed as ‘^’ is input as ‘ I - >’. 

SYi ^ SY( denotes the map that takes the symbol SYi to the symbol SY(. 
The mapped symbols in the list must be distinct. Overloaded operation sym- 
bols and predicate symbols may be disambiguated by explicit qualihcation; 
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when SYi is not qualified, the effect is as if all (sort, operation, or predicate) 
symbols declared with the name SYi (other than those explicitly mapped as 
fully qualihed symbols) in the current environment are mapped uniformly to 
SYI. 

Optionally, the list may be sectioned into sub-lists by inserting the key- 
words ‘sorts’, ‘ops’, ‘preds’ (or their singular forms), which explicitly indi- 
cate that the subsequent symbols are of the corresponding kind: 

sorts 5i ^ 5^, . . ., ops fi ^ //, . . ., preds pi ^ . . . 

As with signature declarations in basic specihcations, there is no restriction 
on the order of the various sections of the list. 

An identity map ^ SYi SYS may be simply written ‘‘SYS . Thus a symbol 
list may be regarded as a special case of a symbol mapping. 

The list determines a set of qualihed symbols, obtained from the hrst 
components of the listed symbol maps with reference to a given signature, 
together with a mapping of these symbols to qualihed symbols obtained from 
the second components of the listed symbol maps. The order in which symbol 
maps are listed is not signihcant (except regarding their position in relation 
to any specihed kinds). 



4.6 Compound Identifiers 

SORT-ID ::= ... | COMP-SORT-ID 

MIX-TOKEN ::= ... | COMP-MIX-TOKEN 

COMP-SORT-ID ::= comp-sort-id WORDS ID+ 

COMP-MIX-TOKEN ::= comp-mix-token ID+ 

This extension of the syntax of identihers for sorts, operations, and predi- 
cates is of relevance to generic specihcations. An ordinary compound iden- 
tifier COMP-SORT-ID is written ‘/[A, . . . , 4i]’; a mixhx compound identiher 
COMP-MIX-TOKEN is written by inserting ‘[A, . . . , A]’ directly after the last 
(non-placeholder) mixhx token of the identiher. (Compound ‘invisible’ iden- 
tihers without any tokens are not allowed.) Note that declaration of both 
compound identihers and mixhx identihers as operation symbols in the same 
local environment may give rise to ambiguity, when they involve overlapping 
sets of mixhx tokens. 

The components A may (but need not) themselves identify sorts, opera- 
tions, or predicates that are specihed in the declared parameters of a generic 
specihcation. 

When such a compound identiher is used to name, e.g., a sort in the body 
of a generic specihcation, the translation determined by htting arguments to 
parameters applies to the components Ar • • Jn as well. Thus instantiations 
with different arguments generally give rise to different compound identihers 
for what would otherwise be the same sort, which avoids unintended identih- 
cations when the instantiations are united. 
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For example, a generic specification of sequences of arbitrary elements 
might use the simple identiher Elem for a sort in the parameter, and a com- 
pound identiher Seq[Elem] for the sort of sequences in the body. Fitting vari- 
ous argument sorts to Elem in different instantiations then results in distinct 
sorts of sequences. 

Subsort embeddings between component sorts do not induce subsort em- 
beddings between the compound sorts: when desired, these have to be declared 
explicitly. For example, when Nat is declared as a subsort of /nt, we do not 
automatically get Seq[Nat] embedded as a subsort of Seq[Int] in signatures 
containing all these sorts. 

Instantiation, however, does preserve subsorts: if in a generic specihcation 
we have Elem declared as a subsort of Seq[Elem]^ where Elem is a param- 
eter sort, then in the result of instantiation of Elem by Nat^ one does get 
Nat automatically declared as a subsort of Seq[Nat\. Compound identihers 
must not be identihed through the identihcation of components by the ht- 
ting morphism. For example, if the body of a generic specihcation contains 
both List[Eleml] and List[Elem2]^ the htting morphism must not map both 
Eleml and Elem2 to Nat^ otherwise the instantiation is not a pushout. 

Higher-order extensions of Casl are expected to provide a more semantic 
treatment of parametrized sorts, etc. 
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Architectural Specifications 



Section 5.1 explains the main concepts of architectural specihcations. The 
rest of the chapter indicates the abstract and concrete syntax of the con- 
structs of architectural specihcations, and describes their intended interpreta- 
tion, extending what was provided for basic and structured specihcations in 
the preceding chapters: Sect. 5.2 covers architectural specihcation dehnitions. 
Sect. 5.3 unit declarations and dehnitions. Sect. 5.4 unit specihcations, and 
Sect. 5.5 unit expressions. 



5.1 Architectural Concepts 

The intention with architectural specihcations is primarily to impose structure 
on models, expressing their composition from component units - and thereby 
also a decomposition of the task of developing such models from requirements 
specihcations. This is in contrast to the structured specihcations summarized 
in Chap. 4, where the specihed models have no more structure than do those 
of the basic specihcations summarized in Chaps. 2 and 3. 



5.1.1 Unit Functions 

The component units may all be regarded as unit functions: functions without 
arguments give self-contained units; functions with arguments use such units 
in constructing further units. Note that a resulting unit may be needed for 
use as an argument in more than one application. 

The specihcation of a unit function indicates the properties to be as- 
sumed of the arguments, and the properties to be guaranteed of the result. 
Such a specihcation provides the appropriate interfaces for the development 
of the function. In Casl, self-contained units are simply models as dehned 
in Chaps. 2 and 3, and their properties are expressed by ordinary (usually: 
named) specihcations. 
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Thus a unit function maps models of argument specifications to models of 
a result specification. A specification of such a function can be simply a list 
of the argument specifications together with the result specification. Thinking 
of argument and result specifications as types of models, a specification of a 
unit function may be regarded as a function type. 

An entire architectural specification is a collection of unit function specifi- 
cations, together with a description of how the functions are to be composed 
to give a resulting unit. A model of an architectural specification is a collec- 
tion of unit functions with the specified types or definitions, together with the 
result of composing them as described. 



5.1.2 Persistency and Compatibility 

The intention is that a unit function should actually make use of its arguments. 
In particular, it should not re-implement the argument specifications. This is 
ensured by requiring the unit function to be persistent: the reduct of the result 
to each argument signature yields exactly the given arguments. 

As a consequence, the result signature has to include each argument sig- 
nature - any desired hiding has to be left to when functions are composed. 
Moreover, since each symbol in the union of the argument signatures has 
to be implemented the same way in the result as in each argument where 
it occurs, the arguments must already have the same implementation of all 
common symbols. In the absence of subsorts, this is sufficient to allow one to 
unambiguously amalgamate arguments into a single model over the union of 
argument signatures. When subsorts are present, extra conditions to ensure 
that implicit subsort embeddings can be defined unambiguously in such an 
amalgamated model may be necessary. Let us call arguments satisfying such 
a requirement compatible. 

Hence the interpretation of the specification of a unit function is as all 
persistent functions from compatible tuples of models of the argument specifi- 
cations to models of the result specification. When composing such functions, 
care must be taken to ensure that arguments are indeed compatible. Notice 
that if two arguments have the same signature, the arguments must be iden- 
tical. It is not possible to specify a function that should take two arguments 
that implement the same signature independently - although one can get the 
same effect, by renaming one or both of the argument signatures. 



5.2 Architectural Specification Definitions 

ARCH-SPEC-DEFN : := arch-spec-defn ARCH -SPEC -NAME ARCH-SPEC 
ARCH-SPEC ::= BASIC-ARCH-SPEC I ARCH- SPEC-NAME 
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An architectural specification definition ARCH-SPEC-DEFN is written: 

arch spec ASN = 

ASP 

end 

where the terminating ‘end’ keyword is optional. 

It dehnes the name ASN to refer to the architectural specihcation ASP^ 
extending the global environment (which must not already include a dehnition 
for ASN). The local environment given to ASP is empty. 

ARCH-SPEC-NAME ::= SIMPLE-ID 

An architectural specihcation name ARCH-SPEC-NAME is normally displayed in 
a Small- Caps font, and input in mixed upper and lower case. 

A reference in an architectural specihcation ARCH- SPEC to an architectural 
specihcation named ASN is simply written as the name itself ^ ASN \ It refers 
to the current global environment, and is well-formed only when the global 
environment includes an architectural specihcation dehnition for ASN. The 
enclosing dehnition then merely introduces a synonym for a previously-dehned 
architectural specihcation. 

BASIC-ARCH-SPEC : := basic-arch-spec UNIT-DECL-DEFN+ RESULT-UNIT 
UNIT-DECL-DEFN : := UNIT-DECL | UNIT-DEFN 
RESULT-UNIT : := result-unit UNIT-EXPRESSION 

A basic architectural specihcation BASIC-ARCH-SPEC is written: 

units UDi] ... UDn] result UE; 

where both the last two semicolons are optional. 

It consists of a list of unit declarations and dehnitions UDi, ..., UD^ 
together with a unit expression UE describing how such units are to be com- 
posed. A model of such an architectural specihcation consists of a unit for 
each UDi^ and the composition of these units as described by UE. 



5.3 Unit Declarations and Definitions 

The visibility of unit names in architectural specihcations is linear: each name 
has to be declared or dehned before it is used in a unit expression; and no 
unit name may be introduced more than once in a particular architectural 
specihcation. Note that declarations and dehnitions of units do not affect the 
global environment: a unit may be referenced only within the architectural 
specihcation in which it occurs. 
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5.3.1 Unit Declarations 

UNIT-DECL ::= unit-decl UNIT-NAME UNIT-SPEC UNIT-IMPORTED 
UNIT-IMPORTED ::= unit -imported UNIT-TERM* 

UNIT-NAME ::= SIMPLE-ID 

A unit declaration UNIT-DECL is written: 

UN : USP given UTi,. . . ,UTn 

When the list UNIT-TERM* of imported unit terms is empty, it is simply writ- 
ten: 

UN : USP 

It provides not only a unit specification USP but also a unit name UN ^ which 
is used for referring to the unit in subsequent unit expressions, so that the 
same unit may be used more than once in a composition. 

The UNIT- IMPORTED lists any units UTi^ . . . ^UT^ that are imported for 
the implementation of the declared unit (which corresponds to implementing 
a generic unit function and applying it only once, to the imported units, the 
argument type of the generic function being merely the list of the signatures of 
the UTi). The unit specification USP is treated as an extension of the signa- 
tures of the imported units, thus being given a non-empty local environment, 
in general. 

5.3.2 Unit Definitions 

UNIT-DEFN ::= unit-defn UNIT-NAME UNIT-EXPRESSION 

A unit definition UNIT-DEFN is written: 

UN = UE 

It defines the name UN to refer to the unit resulting from the composition 
described by the unit expression UE. 

5.4 Unit Specifications 

UNIT-SPEC-DEFN ::= unit-spec-def n SPEC-NAME UNIT-SPEC 
UNIT-SPEC ::= UNIT-TYPE | SPEC-NAME | ARCH-UNIT- SPEC 

I CLOSED-UNIT-SPEC 

A unit specification definition UNIT-SPEC-DEFN is written: 

unit spec SN = 

USP 

end 



where the terminating ‘end’ keyword is optional. 
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It provides a name SN for a unit specification USP. The unit specification 
may be a unit type. It may also be the name of another unit specihcation 
(in the context-free concrete syntax, this is indistinguishable from a reference 
to a named structured specihcation in a constant unit type, but the global 
environment determines how the name should be interpreted). It may be an 
architectural specihcation (either a reference to the dehned name of an archi- 
tectural specihcation, or an anonymous architectural specihcation). Finally, it 
may be an explicitly-closed unit specihcation. 

It dehnes the name SN to refer to the unit specihcation USP^ extending 
the global environment (which must not already include a dehnition for SN). 
The local environment given to USP is empty, i.e., the unit specihcation is 
implicitly closed. 

5.4.1 Unit Types 

UNIT-TYPE ::= unit-type SPEC* SPEC 
A unit type is written: 

SPi X . . . X SPn ^ SP 

When the list SPEC* of argument specihcations is empty, the unit type is 
simply written ^SP\ The sign displayed as ‘x’ may be input as ‘x’ in ISO 
Latin- 1, or as ‘*’ in ASCII. The sign displayed as is input as 

A unit satishes a unit type when it is a persistent function that maps 
compatible tuples of models of the argument specihcations SPi , . . . , SPn to 
models of their extension by the result specihcation SP. 

5.4.2 Architectural Unit Specifications 
ARCH-UNIT-SPEC ::= arch-unit -spec ARCH-SPEC 

An architectural unit specihcation ARCH-UNIT-SPEC is written: 
arch spec ASP 

A unit satishes ‘arch spec ASP^ when it is the result unit of some model 
of ASP. Given a (basic or named) architectural specihcation ASP^ note the 
difference between ^ASP^ and ‘arch spec ASP^: the former is an architectural 
specihcation, while the latter is a coercion of the architectural specihcation 
ASP to a unit specihcation. 

5.4.3 Closed Unit Specifications 
CLOSED-UNIT-SPEC ::= closed-unit-spec UNIT-SPEC 

A closed unit specihcation CLOSED-UNIT-SPEC is written: 
closed USP 

It determines the same type as USP determines in the empty local environ- 
ment, thus ensuring the closedness of USP. 
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5.5 Unit Expressions 

UNIT-EXPRESSION : := unit -express ion UNIT-BINDING* UNIT-TERM 
UNIT-BINDING : := unit-binding UNIT-NAME UNIT-SPEC 

A unit expression with some unit bindings is written: 

XUNi : USPi] . . . ; UNn : USPn • UT 

The sign displayed as ‘A’ is input as ‘lambda’. The sign displayed as ‘ ’ may 

be input as in ISO Latin- 1, or as ‘ ’ in ASCII. When the list of unit bindings 
is empty, just the unit term WT’ is written. 

It describes a composition of units declared (or defined) in the enclosing 
architectural specification. The result unit is a function, mapping the argu- 
ments specified by the unit bindings (if any) to the unit described by the unit 
term UT. The unit names LWi, ..., UN^ for the arguments must be dis- 
tinct, and not include the names of units previously declared in the enclosing 
architectural specification. 

The unit bindings for the arguments (which are like unit declarations but 
with no possibility of importing other units) in a unit expression are for (non- 
parametrized) units that are required to build the result, but are not directly 
provided yet. This allows for compositions which express partial architectural 
specifications that depend on additional units, and might be used to instan- 
tiate the same composition for various realizations of the required units. 



5.5.1 Unit Terms 

UNIT-TERM ::= UNIT-REDUCTION | UNIT-TRANSLATION | AMALGAMATION 
I LOCAL-UNIT I UNIT-APPL 

Unit terms provide counterparts to most of the constructs of structured spec- 
ifications: translations, reductions, amalgamations (corresponding to unions), 
local unit definitions, and applications (corresponding to instantiations). 

Unit terms use the same notation as structured specifications - but with 
a crucially different semantics, however. This is easiest to notice when con- 
sidering the difference between union and amalgamation, as well as between 
translation and unit translation. For units, enough sharing is required so that 
the constructs, as applied to the given units, will always make sense and 
produce results. This is in contrast with the constructs for structured specifi- 
cations, where well-formed unions or (non- injective) translations of consistent 
specifications might result in inconsistencies. 

The sharing between symbols is understood here semantically: two symbols 
share if they coincide semantically. However, there is also a static semantics 
(with the corresponding static analysis supported by Casl tools) that exploits 
situations where symbols required to share in fact originate from the same 
symbol in some unit declaration or definition. Such direct information should 
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be sufficient to discharge the verffication conditions implicit in the above se- 
mantic requirement in most typical cases. This is simplest when no subsorting 
constructs are involved. The presence of subsorts, and the properties that sub- 
sort embeddings and overloaded operations and predicates must satisfy, make 
the static analysis more complex [62] (but still tractable in practical exam- 
ples). 

Taking the unit type of each unit name from its declaration, the unit term 
must be well-typed. All the constructs involved must get argument units over 
the appropriate signatures. 



Unit Translations 

UNIT-TRANSLATION : := unit -translation UNIT-TERM RENAMING 
A unit translation is written: 

UT R 

where the renaming R is written ‘with SM\ and determines a mapping of 
symbols, cf. Sect. 4.2.1. 

It allows some of the unit symbols to be renamed. Any symbols that hap- 
pen to be glued together by the renaming must share. 



Unit Reductions 

UNIT-REDUCTION ::= unit-reduction UNIT-TERM RESTRICTION 
A unit reduction is written: 

UT R 

where the restriction R is written ‘hide SU or ‘reveal SM\ and determines 
a set of symbols, and in the latter case also a mapping of them, cf. Sect. 4.2.2. 

It allows parts of the unit to be hidden and other parts to be simultaneously 
renamed. 



Amalgamations 

AMALGAMATION : := amalgamation UNIT-TERM+ 
An amalgamation is written: 

UTi and . . . and UTn 



It produces a unit that consists of the components of all the amalgamated 
units put together. Compatibility of the unit terms must be ensured. 
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Local Units 

LOCAL-UNIT ::= local-unit UNIT-DEFN+ UNIT-TERM 
A local unit is written: 

local UDi; . . . ; within UT 

where the final ‘ ; ’ may be omitted. 

This allows for naming units that are locally defined for use in a unit term, 
these units being intermediate results that are not to be visible in the models 
of the enclosing architectural specification. 



Unit Applications 

UNIT-APPL ::= unit-appl UNIT-NAME FIT-ARG-UNIT* 

A unit application UNIT-APPL is written: 

UN[FAUi]...[FAUn] 

It refers to a generic unit named UN that has already been declared or defined 
in the enclosing architectural specification, providing a fitting argument FA Ui 
for each declared parameter (in the same order). 

FIT-ARG-UNIT ::= f it-arg-unit UNIT-TERM SYMB- MAP -ITEMS* 

A fitting argument FA Ui is written: 

UT' fit SMi 

When the symbol mapping SMi is empty, just the unit term UT^ is written. 

The fitting argument fits the argument unit given by the unit term UT^ 
to the corresponding formal argument for the generic unit, via a signature 
morphism which is determined by the symbol mapping SMi in the same way 
as for generic specifications. The result of such ‘fitting’ (which is the reduct of 
the argument unit by the signature morphism) must be a model of the corre- 
sponding parameter specification in the declaration of the unit UN ^ otherwise 
the unit application is undefined. 

When there is more than one parameter, the separate fitting argument 
morphisms have to be compatible; moreover, the argument units determined 
by UTl must be compatible as well. 

Then, the unit function denoted by UN is applied to the fitted argument 
units. The result is translated by the fitting signature morphisms extended 
to the signature of the result specification in the declaration of UN (just as 
for instantiations of generic specifications) and finally amalgamated with the 
argument units, yielding the overall result of the unit application. 
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Specification Libraries 



Section 6.1 introduces the concepts underlying the specihcation libraries pro- 
vided by Casl. The rest of the chapter indicates the abstract and concrete 
syntax of the library constructs, and describes their intended interpretation, 
extending what was provided for basic, structured, and architectural specih- 
cations in the preceding chapters. Section 6.2 presents the constructs of local 
libraries. Such libraries are not dependent on other libraries. Section 6.3 con- 
siders constructs for referencing distributed libraries. Finally, Sect. 6.4 explains 
the form and intended interpretation of library names. 



6.1 Library Concepts 

Specihcations may be named by definitions and collected in libraries. In the 
context of a library, the (re) use of a specihcation may be replaced by a ref- 
erence to it through its name. The current association between names and 
the specihcations that they reference is called the global environment] it may 
vary throughout a library: with linear visibility^ as in Casl, the global envi- 
ronment for a named specihcation is determined exclusively by the dehnitions 
that precede it. When overriding is forbidden, as in Casl, each valid reference 
to a particular name refers to the same dehned entity. 

The local environment given to each named specihcation in a library should 
be independent of the other specihcations in the library (in Casl, it is empty). 
Thus any dependence between the specihcations is always apparent from the 
explicit references to the names of specihcations. 

A library may be located at a particular site on the Internet. The library 
is referenced from other sites by a name which determines the location and 
perhaps identihes a particular version of the library. To allow libraries to be 
relocated without this invalidating existing references to them, library names 
may be interpreted relative to a global directory that maps names to URLs. 
Libraries may also be referenced directly by their (relative or absolute) URLs, 
independently of their registration in the global directory. 
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A library may incorporate the downloading of (the semantics of) named 
specihcations from (perhaps particular versions of) other libraries, whenever 
the library is used. To ensure continuous access to specihcations despite tem- 
porary failures at a particular library site, registered libraries may be mirrored 
at archive sites. 

The semantics of a specihcation library is the name of the library together 
with a map taking each specihcation name dehned in it to the semantics of 
that specihcation. The initial global environment for the library is empty. 



6.2 Local Libraries 

LIB-DEFN ::= lib-defn LIB-NAME LIB-ITEM* 

LIB-ITEM ::= SPEC-DEFN | VIEW-DEFN | ARCH-SPEC-DEFN | UNIT-SPEC-DEFN 
A library dehnition LIB-DEFN is written: 
library LN LIi . . . Lin 

Each library item LIi starts with a distinctive keyword, and may be terminated 
by an optional ‘end’. 

The library dehnition provides a collection of specihcation (and perhaps 
also view) dehnitions. It is well-formed only when the dehned names are dis- 
tinct, and not referenced until (strictly) after their dehnitions. The global 
environment for each dehnition is that determined by the preceding dehni- 
tions. Thus a library in Casl provides linear visibility, and mutual or cyclic 
chains of references are not allowed. 

The local environment for each dehnition is empty: the symbols declared by 
the preceding specihcations in the library are only made available by explicit 
reference to the name of the specihcation concerned. 

Each specihcation dehnition in a library must be self-contained (after re- 
solving references to names dehned in the current global environment), deter- 
mining a complete signature - fragments of specihcations cannot be named. 

A library dehnition determines a library name, together with a map from 
names to the semantics of the named specihcations. 



6.3 Distributed Libraries 



LIB-ITEM 
DOWNLOAD- ITEMS 
ITEM-NAME- OR-MAP 
ITEM-NAME-MAP 
ITEM-NAME 



= . . . I DOWNLOAD- ITEMS 

= download-items LIB-NAME ITEM-NAME- 0R-MAP+ 
= ITEM-NAME | ITEM-NAME-MAP 
= item-name-map ITEM-NAME ITEM-NAME 
= SIMPLE- ID 



The syntax of local libraries is here extended with a further sort of library 
item, for use with distributed libraries. 




1:6.4 Library Names 



59 



A downloading DOWNLOAD- ITEMS is written: 

from LN get INi ^ IN[, . . . , INn ^ IN^ end 

where the terminating ‘end’ keyword is optional. An identity map ‘‘INi ^ INi 
may be simply written NNi\ 

The downloading specihes which dehnitions to download from the remote 
library named LA, changing the remote names INi to the local names /A/. The 
semantics corresponds to having already replaced all references in the down- 
loaded dehnitions by the corresponding (closed) specihcations; cyclic chains 
of references via remote libraries are not allowed. The download items show 
exactly which specihcation names are added to the current global environment 
of the library in which they occur, allowing references to named specihcations 
to be checked locally (although not whether the kind of specihcation to be 
downloaded from the remote library is consistent with its local use). 



6.4 Library Names 



LIB-NAME ::= LIB-ID | LIB-VERSION 

LIB-VERSION ::= lib-version LIB-ID VERS I ON -NUMBER 
VERSION-NUMBER ::= version-number NUMBER+ 

A library name LIB-NAME without a VERS I ON -NUMBER is written simply as a 
library identiher LI. A library name LIB-NAME with version numbers Ai, . . . , 
Nn is written: 

LI version Ai A^ 

The lists of version numbers are ordered lexicographically on the basis of the 
usual ordering between natural numbers. 

The library name of a library dehnition determines how the library is to 
be referenced from other libraries; its interpretation as a URL determines 
the primary location of the library (any copies of a library are to retain the 
original name). 

When the name of a dehned library is simply a library identiher LIB- ID, 
it must be changed to an explicit library version LIB-VERSION before dehning 
further versions of that library. A library identiher without an explicit version 
in a downloading construct always refers to the current version of the iden- 
tihed library: the one with the largest list of version numbers (which is not 
necessarily the last-created version). 

LIB-ID ::= DIRECT-LINK | INDIRECT-LINK 

DIRECT-LINK ::= direct-link URL 
INDIRECT-LINK ::= indirect-link PATH 

A direct link to a library is simply written as the URL of the library. The 
location of a library is always a directory, giving access not only to the in- 
dividual specihcations dehned by the current version of the library but also 
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to previously-defined versions, various indexes, and perhaps other documen- 
tation. 

An indirect link is written: 

Fhl...lFIn 

where each hie identiher Fli is a valid hie name, as for use in a path in a 
URL. An indirect link is interpreted as a URL by the current global library 
directory. 
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Sublanguages and Extensions 



From Casl, simpler languages (e.g., for interfacing with existing tools) are ob- 
tained by restriction, and Casl is also extended in more advanced languages 
(e.g., higher-order). Casl strikes a balance between simplicity and expressive- 
ness. 



7.1 Sublanguages 

This section dehnes various frequently used sublogics as sublanguages of Casl. 
Different existing algebraic specihcation language implementations have a nat- 
ural extension in Casl, so that specihcations in such languages can be trans- 
lated into Casl and can be combined with other Casl specihcations. Tool 
support for Casl specihcations can be obtained for specihcations within given 
sublanguages by translating Casl specihcations for those sublanguages into 
the corresponding languages of given tools. 

Note that the sublanguages dehned here only address basic specihcations. 
Casl structured and architectural specihcations as well as libraries remain 
the same for all the sublanguages. 



7.1.1 A Language for Naming Sublanguages 

A concise notation for a variety of sublanguages of Casl can be obtained by as- 
signing tokens to the various features of Casl. This leads to a two-component 
name for the various sublanguages that can be obtained by combining Casl’s 
features. The hrst component is a vector of tokens. The presence (or absence) 
of a token denotes the presence (or absence) of a corresponding feature, cf. 
Sect. 7.1.2. The second component determines the level of expressiveness of 
axioms due to Sect. 7.1.3. 
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We assign the following tokens to features: 

• Sub stands for subsorting. 

• P stands for partiality. 

• C stands for sort generation constraints. 

• An equality symbol (=) stands for equality. 

Any subset of this set of four tokens, when combined with the notation for 
denoting a particular level of expressiveness, denotes the sublanguage obtained 
by equipping the level of expressiveness with the features expressed by the 
tokens (technically, this is achieved by intersecting all those sublanguages 
which omit a feature that is not in the set). 

In order to be consistent with standard terminology, the predicate feature 
is combined with the levels of axiomatic expressiveness (Sect. 7.1.3), as follows. 
With predicates, we have: 

• FOL stands for the unrestricted form of axioms (hrst-order logic). 

• GHorn stands for the restriction to generalized positive conditional logic. 

• Horn stands for the restriction to positive conditional logic. 

• Atom stands for the restriction to atomic logic. 

Without predicates, we have: 

• FOAlg stands for the unrestricted form of axioms (hrst-order logic). 

• GCond stands for the restriction to generalized positive conditional logic. 

• Gond stands for the restriction to positive conditional logic. 

• Eq stands for the restriction to atomic logic. 

Finally, we adopt the convention that the equality sign = is always put at 
the end, as a superscript. 



Some Interesting Sublanguages of Case 

Here are some examples of what the above naming scheme means in practice: 

SubPCFOL=: 

(read: subsorted partial constraint hrst-order logic with equality). This is 
the logic of Casl itself. 

SubPFOL=: 

(read: subsorted partial hrst-order logic with equality). Casl without sort 
generation constraints. This is described in [13]. 

FOL=: 

Standard many-sorted hrst-order logic with equality. 

PFOL=: 

Partial many-sorted hrst-order logic with equality. 

FOAlg=: 

First-order algebra (i.e., no predicates). 
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SubPHorn^: 

This is the positive conditional fragment of Casl. It has two important 
properties: 

• Initial models and free extensions exist (see [41]). 

• Using a suitable encoding of subsorting and partiality, one can use 
conditional term rewriting or paramodulation [51] for theorem proving. 

SubPCHorn=: 

The positive conditional fragment plus sort generation constraints. Com- 
pared with SubPHorn^ ^ one has to add induction techniques to the the- 
orem proving tools. 

PCond^i 

These are Burmeister’s partial quasi- varieties [10] modulo the fact that 
Burmeister does not have total function symbols. But total function sym- 
bols can be easily simulated by partial ones, using totality axioms, as in 
the partly total algebras of [11]. A suitable restriction leads to Reichel’s 
HEP-theories [55]. Meseguer’s Rewriting Logic [35] can be embedded into 
PCond^ . 

Horn^: 

This is Eqlog [22, 51]. By further restricting this we get Membership 
Equational Logic [36], Equational Type Logic [33] and Unihed Algebras 
[48]. Of course. Membership Equational Logic, Equational Type Logic 
and Unihed Algebras are not just restrictions of Horn^ ^ but all have been 
invented in order to represent more complex logics within a subset of 
Horn^ . 

Horn: 

Logic Programming (Pure Prolog) [32]. 

SubCond^: 

Subsorted conditional logic. This is similar but not equal to OBJ3 [25], 
see [41], the main difference being the treatment of subsorts. 

Cond^: 

This is many-sorted conditional equational logic [66] . 

SubPAtom: 

The atomic subset of Casl. Unconditional term rewriting becomes appli- 
cable. 

SubPCAtom: 

The atomic subset plus sort generation constraints. 

Eq=: 

This is classical equational logic [24]. 

CEq=: 

Equational logic plus sort generation constraints. 

In the literature, some of the above institutions are typically dehned in a way 
allowing empty carrier sets, while Casl excludes empty carriers. This problem 
is discussed in [41]. 
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7.1.2 A List of Orthogonal Features 

In this section, we describe a number of Casl’s features negatively by speci- 
fying, for each feature, the sublanguage of Casl that leaves out exactly that 
feature. This is possible since Casl is already the combination of all its fea- 
tures. A combination of only some of Casl’s features can then be obtained by 
intersecting all those sublanguages that exclude exactly one of the undesired 
features. Intersection of languages as institutions is formally dehned in [41]. 



Partiality 



As indicated above, we now specify the sublanguage of Casl without partiality. 
We cross out those parts of the Casl grammar given in Sect.. 11:2.1 that have 
to be removed in order to remove the possibility to declare and use partial 
functions: 



OP-TYPE 
OP -HEAD 
ALTERNATIVE 
COMPONENTS 
TERM 



= TOTAL-OP-TYPE | PARTIAL OP TYPE 

= TOTAL-OP-HEAD | PARTIAL OP HEAD 

= TOTAL-CONSTRUCT | PARTIAL CONSTRUCT 

= total-select I PARTIAL SELECT | SORT 

= SIMPLE- ID I QUAL-VAR | APPLICATION 
I SORTED-TERM | CONDITIONAL | CAST 



Note that we can keep DEFINEDNESS, EXISTL-EQUATION and STRONG-EQUA- 
TION, since in the total case, the former is semantically equivalent to true 
and the latter two are equivalent. 



Predicates 

This is easy as well: from the Casl grammar we just have to remove the 
possibility to declare and use predicates: 

SIG-ITEMS ::= SORT-ITEMS I OP-ITEMS | PRED ITEMS 

I DATATYPE- ITEMS 

ATOM ::= TRUTH | PREDICATION | DEFINEDNESS 

I EXISTL-EQUATION | STRONG-EQUATION 

Subsorting 

Just remove everything from Sect. 11:2.1.2 from the grammar. 
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Sort Generation Constraints 

To remove sort generation constraints, just change the grammar as follows: 

BASIC-ITEMS ::= SIG-ITEMS | FREE DATATYPE | SORT GEN 

I VAR-ITEMS I LOCAL-VAR-AXIOMS I AXIOM-ITEMS 



Equality 

To remove equations, just change the grammar as follows: 

ATOM ::= TRUTH | PREDICATION | DEFINEDNESS 

-\ EXISTL - EQUATION | STRONG - EQUATION 

7.1.3 A List of Levels of Expressiveness 

In this and the following section, the sublanguages are identihed in a purely 
syntactical way, namely by restricting the grammar for the Casl abstract 
syntax (cf. Sect. 11:2.1). Thus, given a particular specihcation, a tool can 
easily determine the minimal sublanguage of Casl to which the specihcation 
belongs. 

We start with the four different level of axiomatic expressiveness. 



First-Order Logic 

This is given by the unrestricted Casl grammar. 



Positive Conditional Logic 

Positive conditional logic more precisely means: universally-quantihed pos- 
itive conditional logic. Usually this means that formulas are restricted to 
universally-quantihed implications that consist of a premise that is a con- 
junction of atoms, and a conclusion that is an atom: 

Vxi:5i . . .WXn’.Sn • A . . . A (fn ^ (f 

Positive conditional means that the atoms must not implicitly contain nega- 
tive parts. Now strong equations are implicit implications {if both sides are 
dehned, then they are equal, or both sides are undehned) and thus may not 
occur in the premises of positive conditional axioms. The reason for this is 
that we want to have initial models for positive conditional axioms, and these 
do not exist if strong equations are allowed in the premises (see [12, 3]). 

The new grammar for formulas, which describes a subset of Casl (even 
though it uses some new nonterminals, written THUS)^ is as follows: 
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FORMULA 


1 


QUANTIFICATION I CONJUNCTION I DISJUNCTION 
IMPLICATION 1 EQUIVALENCE I NEGATION I ATOM 


QUANTIFICATION 


: : = 


quantification QUANTIFIER VAR-DECL+ FORMULA 


QUANTIFIER 


: : = 


universal -| — oxistontial — | unique oxistontial 


P-CONJUNCTION 


: : = 


conjunction P-AT0M+ 


IMPLICATION 


: : = 


implication P-CONJUNCTION ATOM 


P-ATOM 


1 


TRUTH 1 PREDICATION | DEFINEDNESS 
EXISTL-EQUATION I STRONG EQUATION 


ATOM 


1 


TRUTH 1 PREDICATION I DEFINEDNESS 
EXISTL-EQUATION I STRONG-EQUATION 


TRUTH 


: : = 


true -I — false 


SUBSORT-DEFN 


: : = 


subsort-defn SORT VAR SORT P-ATOM 



P-CON JUNCTION allows a conjunction in the premise of an implication. 
Note that P-ATOM is needed to forbid strong equations in the premise. 

Since subsort dehnitions are reduced to equivalences (and can be further 
reduced to two implications), in order to obtain a positive conditional formula, 
we must ensure that the dehning formula is a P-ATOM. 



Generalized Positive Conditional Logic 



In the following, we generalize the above form of positive conditional formulas 
by allowing also: 

• conjunctions of atoms in the conclusion (they can be removed by writing, 
for each conjunct, an implication with the same premise and the conjunct 
as conclusion), 

• nested conjunctions in the premise and conclusion (they can be flattened), 

• equivalences in addition to implications (an equivalence is equivalent to 
two implications), and 

• nesting of conjunction and universal quant ihcat ion (by the rules for prenex 
normal form [64], we can always shift the quantihers inside, getting a 
conjunction of universally quantihed implications). 

Each formula of this more general kind is equivalent to a set of formulas 
of the standard conditional kind. Thus there is an easy transformation from 
generalized positive conditional logic to plain positive conditional logic. 

The new grammar for formulas is as follows 



FORMULA 



QUANTIFICATION 

QUANTIFIER 

F-CONJUNCTION 

P-CONJUNCTION 



::= QUANTIFICATION | C-CON JUNCTION 
I F-CONJUNCTION \ DISJUNCTION 
I IMPLICATION I EQUIVALENCE | NEGATION | ATOM 
::= quantification QUANTIFIER VAR-DECL+ FORMULA 
: := universal -| — oxistontial — | — unique exist ontial 
::= conjunction F0RMULA+ 

::= conjunction PREMISE+ 
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C-CONJUNCTION 

PREMISE 

CONCLUSION 

IMPLICATION 

EQUIVALENCE 



conjunction CONCLUSION+ 
P-CONJUNCTION I P-ATOM 
C-CONJUNCTION \ ATOM 
implication PREMISE CONCLUSION 
equivalence PREMISE PREMISE 



P-ATOM 

ATOM 

TRUTH 



= TRUTH I PREDICATION | DEFINEDNESS 
I EXISTL-EQUATION | STRONG EQUATION 
= TRUTH I PREDICATION | DEFINEDNESS 
I EXISTL-EQUATION | STRONG-EQUATION 
= true -I — false 



SUBSORT-DEFN 



subsort-defn SORT VAR SORT PREMISE 



P-CONJUNCTION and C-CONJUNCTION allow nested conjunctions in the 
premises and conclusion of an implication. F-CONJUNCTION allows nesting of 
quantification and conjunction. 



Atomic Logic 



This is the restriction of conditional logic to unconditional (i.e., universally 
quantified atomic) formulas. Strong equations are only allowed if at least one 
of the sides of the equation consists entirely of total function symbols and 
variables; this is indicated by the nonterminal written ‘(STRONG-EQUATION)’ 
below. Other strong equations are removed due to their conditional nature: in 
[37] it is proved that strong equations can simulate positive conditional formu- 
las. Since definitions of partial functions involve strong equations with possibly 
partial function symbols occurring on both sides of the equations, these are 
removed as well. Likewise, associativity and commutativity attributes are re- 
moved. Finally, due to the conditional nature of subsort definitions we have 
to forbid them entirely. 

SORT-ITEM ::= SORT-DECL | SUBSORT-DECL | ISO-DECL | SUBSORT DEFN 



OP-HEAD ::= TOTAL-OP-HEAD | PARTIAL OP HEAD 



BINARY-OP-ATTR 

FORMULA 

QUANTIFICATION 

QUANTIFIER 

F-CONJUNCTION 



: := assoc-op-attr | | comm - op - attr | idem-op-attr 

::= QUANTIFICATION | F-CONJUNCTION \ DISJUNCTION 

j IMPLICATION I EQUIVALENCE | NEGATION | P-ATOM 

::= quantification QUANTIFIER VAR-DECL+ FORMULA 
: := universal -| — oxistontial — | unique exist ontial 
::= conjunction F0RMULA+ 



P-ATOM ::= TRUTH | PREDICATION | DEFINEDNESS 

I EXISTL-EQUATION | (STRONG-EQUATION) 



TRUTH 



true -I — false 
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7.2 Extensions 

Various extensions of Casl have been proposed. They have not been developed 
by CoFI as a whole, but by subgroups of CoFI, and have not yet been approved 
by CoFI and IFIP WG1.3. For a language to be approved as an extension of 
Casl, its syntax and intended semantics have to be documented in relation to 
the Casl Summary (i.e., the foregoing chapters of this part of the reference 
manual), and it has to include most constructs of Casl- respecting their usual 
syntax and semantics. 

Most of the extensions are dehned at the level of Casl basic specihcations. 
The exceptions are CoCasl, HetCasl and the rehnement language: these 
languages also dehne new structuring constructs. 



7.2.1 Higher- Order and Coalgebraic Extensions 
HasCasl 

HasCasl [60, 61] is an extension of Casl that establishes a connection with 
functional programming languages such as Haskell. To this end, Casl has been 
extended by features that support the type system of these languages, in par- 
ticular higher-order types, type constructors, and parametric polymorphism. 
The HasCasl semantics is tuned to allow program development by specih- 
cation rehnement, while at the same time staying close to the set-theoretic 
semantics of hrst-order Casl. The number of primitive concepts in the logic 
has been kept as small as possible; various extensions to the logic can be for- 
mulated within the language itself. Together with the HasCasl tool support, 
an environment is created for the specihcation and formal implementation of 
software, which allows the coherent development of formal specihcations and 
executable functional programs in a common framework. 

CoCasl 

CoCasl [46] is a simple coalgebraic extension of Casl. CoCasl admits the 
nested combination of algebraic datatypes and coalgebraic process types. 
CoCasl dualizes Casl’s generated and free types to cogenerated and cofree 
types, and provides a coalgebraic modal logic for these. At the level of struc- 
tured specihcations, Casl’s free construct is dualized to a cofree construct. 



7.2.2 Reactive Extensions 
Casl-Ltl 

Casl-Ltl is an extension of Casl that allows for specihcation of dynamic 
systems by modelling them by means of labelled transition systems and by 
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expressing their properties with temporal formulas. It is based on LTL, a logic- 
algebraic formalism for the specihcation of concurrent systems. A detailed 
summary of the syntax and intended semantics of Casl-Ltl can be found 
in [54]. 

Sb-Casl 

Sb-Casl [4] is an extension of Casl that deals with the specihcation of state- 
based systems using the state- as- algebra approach. In this approach, the state 
of a software system is modeled as an algebra (in Sb-Casl, as an algebra of 
the Casl institution), and operations changing the state as (partial) functions 
on classes of algebras. 

Sb-Casl incorporates ideas from Gurevich’s Abstract State Machines 
(ASM), d-oids by Astesiano and Zucca, and others. In particular, this ex- 
tension combines an operational style of specihcation (in the sense of ASMs) 
with a declarative style (in the sense of Z). 

Csp-Casl 

Csp-Casl [56] is a combination of Casl with the process algebra CSP, fol- 
lowing the paradigm ‘‘integrating a formalism for concurrent aspects with 
algebraic specihcation of static datatypes” [2]. Its novel aspects include the 
use of denotational semantics for the process part, loose semantics for the 
datatypes, and their combination in terms of a two-step semantics leading to 
decomposition theorems concerning an appropriate notion of rehnement. 



7.2.3 Extensions at the Structured Level 
HetCasl 

HetCasl stand for heterogeneous Casl, and allows for mixing of specihcations 
written in different logics (using translations between the logics) [40, 42]. It 
extends Casl only at the level of structuring constructs, by adding constructs 
for choosing the logic and translating specihcations among logics. HetCasl 
is needed when combining specihcations written in Casl with specihcations 
written in its sublanguages and extensions. 



A Simple Refinement Language 

A simple rehnement language built on top of Casl has been proposed in 
[43, 47]. It allows to rehne unit specihcations and architectural specihcations, 
until monomorphic unit specihcations are reached. Under suitable restrictions, 
the latter can then be translated into a programming language. 
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Introduction 



This part of the Casl Reference Manual is concerned with syntax. It makes 
the usual distinction between concrete syntax and abstract syntax: the former 
deals with the representation of specihcations as sequences of characters, and 
with how these sequences can be grouped to form specihcations, whereas the 
latter rehects only the compositional structure of specihcations after they have 
been properly grouped. 

The abstract syntax of Casl plays a particularly central role: not only is it 
the basis for the Casl semantics, which is explained informally in Part I and 
dehned formally in Part III, but also the abstract syntax of Casl specihcations 
can be stored in libraries, so that tools can process the specihcations without 
having to (re) parse them. 

In acknowledgment of the importance of abstract syntax, consideration of 
concrete syntax for Casl was deferred until after the design of the abstract 
syntax - and of most of the details of its semantics - had been settled. The 
presentation of the Casl syntax here rehects the priority given to the abstract 
syntax: 

• Chapter 2 specihes the abstract syntax of Casl; 

• Chapter 3 gives a context-free grammar for Casl specihcations, indicating 
also how ambiguities are resolved; 

• Chapter 4 specihes the grouping of sequences of characters into sequences 
of lexical symbols, and determines their display format; and hnally, 

• Chapter 5 explains the form and use of comments and annotations (which 
are both included in abstract syntax, but have no effect on the semantics 
of specihcations). 

The relationship between the concrete syntax and the abstract syntax is 
rather straightforward - except that mapping the use of mixhx notation in 
a concrete ATOM to an abstract ATOM depends on the declared operation and 
predicate symbols (although not on their prohles). Here, the relationship is 
merely suggested by the use of the same nonterminal symbols in the concrete 
and abstract grammars. 
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Acknowledgement. The design of the abstract syntax of Casl has been heavily in- 
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Abstract Syntax 



The abstract syntax is central to the dehnition of a formal language. It stands 
between the concrete representations of documents, such as marks on paper or 
images on screens, and the abstract entities, semantic relations, and semantic 
functions used for dehning their meaning. 

The abstract syntax has the following objectives: 

• to identify and separately name the abstract syntactic entities; 

• to simplify and unify underlying concepts, putting like things with like, 
and reducing unnecessary duplication. 

There are many possible ways of constructing an abstract syntax, and the 
choice of form is a matter of judgment, taking into account the somewhat 
conflicting aims of simplicity and economy of semantic dehnition. 

The abstract syntax is presented as a set of production rules in which each 
kind of entity is dehned in terms of its sub-kinds: 

SOME-KIND ::= SUB-KIND- 1 | ... | SUB-KIND-n 

or in terms of its constructor and components: 

SOME-CONSTRUCT ::= some- construct COMPONENT-1 ... COMPONENT-n 

The productions form a context-free grammar; algebraically, the nonterminal 
symbols of the grammar correspond to sorts (of trees), and the terminal sym- 
bols correspond to constructor operations. The notation COMPONENT* indicates 
repetition of COMPONENT any number of times; C0MP0NENT+ indicates repeti- 
tion at least once. These repetitions can be replaced by auxiliary sorts and 
constructs, after which it would be straightforward to transform the grammar 
into a Casl library of specihcations using datatype declarations. 

The context conditions for well-formedness of specihcations are context- 
sensitive, and considered as part of the Casl semantics, see Part III. 

Many constructs can have comments and annotations attached to them 
(see Sect. 5.2), but these are not shown in the grammar. 
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2.1 Normal Grammar 

The grammar given in this section has the property that there is a nonterminal 
for each abstract construct (although an exception is made for constant con- 
structs with no components). Section 2.2 provides an abbreviated grammar 
dehning the same abstract syntax. 

The following nonterminal symbols correspond to the lexical syntax, and 
are left unspecihed in the abstract syntax: WORDS, DOT-WORDS, SIGNS, DIGIT, 
DIGITS, NUMBER, QUOTED-CHAR, PLACE, URL, and PATH. 

2.1.1 Basic Specifications 

BASIC-SPEC ::= basic-spec BASIC-ITEMS* 

BASIC-ITEMS ::= SIG-ITEMS I FREE-DATATYPE | SORT-GEN 

I VAR- ITEMS I LOCAL- VAR- AXIOMS I AXIOM- ITEMS 

SIG-ITEMS ::= SORT-ITEMS I OP-ITEMS I PRED-ITEMS 

I DATATYPE- ITEMS 

SORT-ITEMS ::= sort-items S0RT-ITEM+ 

SORT-ITEM ::= SORT-DECL 

SORT-DECL ::= sort-decl S0RT+ 

OP-ITEMS ::= op-items 0P-ITEM+ 

OP-ITEM ::= OP-DECL | OP-DEFN 

OP-DECL ::= op-decl 0P-NAME+ OP-TYPE OP-ATTR* 

OP-TYPE ::= TOTAL-OP-TYPE | PARTIAL -OP -TYPE 

TOTAL-OP-TYPE ::= total-op-type SORT-LIST SORT 

PARTIAL-OP-TYPE : := partial-op-type SORT-LIST SORT 

SORT-LIST ::= sort-list SORT* 

OP-ATTR ::= BINARY-OP-ATTR | UNIT-OP-ATTR 

BINARY- OP-ATTR : := assoc-op-attr | comm-op-attr | idem-op-attr 

UNIT-OP-ATTR ::= unit-op-attr TERM 

OP-DEFN ::= op-defn OP-NAME OP-HEAD TERM 

OP-HEAD ::= TOTAL-OP-HEAD | PARTIAL -OP -HEAD 

TOTAL-OP-HEAD ::= total-op-head ARG-DECL* SORT 

PARTIAL-OP-HEAD : := partial-op-head ARG-DECL* SORT 

ARG-DECL ::= arg-decl VAR+ SORT 

PRED-ITEMS ::= pred-items PRED-ITEM+ 

PRED-ITEM ::=PRED-DECL | PRED-DEFN 



PRED-DECL 

PRED-TYPE 



::= pred-decl PRED-NAME+ PRED-TYPE 
::= pred-type SORT-LIST 
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PRED-DEFN : : 

PRED-HEAD : : 

DATATYPE- ITEMS : : 

DATATYPE-DECL : : 

ALTERNATIVE : : 

TOTAL-CONSTRUCT : : 

PARTIAL-CONSTRUCT: : 
COMPONENTS : : 

TOTAL- SELECT : : 

PARTIAL-SELECT : : 

FREE-DATATYPE : : 

SORT-GEN : : 

VAR- ITEMS : : 

VAR-DECL : : 

LOCAL-VAR-AXIOMS : : 

AXIOM- ITEMS : : 

AXIOM : : 

FORMULA : : 

QUANTIFICATION : : 

QUANTIFIER : : 

CONJUNCTION : : 

DISJUNCTION : : 

IMPLICATION : : 

EQUIVALENCE : : 

NEGATION : : 

ATOM : : 

TRUTH : : 

PREDICATION : : 

PRED-SYMB : : 

QUAL-PRED-NAME : : 

DEFINEDNESS : : 

EXISTL-EQUATION : : 

STRONG-EQUATION : : 

TERMS : : 

TERM : : 

QUAL-VAR : : 

APPLICATION : : 



= pred-defn PRED-NAME PRED-HEAD FORMULA 
= pred-head ARG-DECL* 

= datatype- items DATATYPE-DECL+ 

= datatype-deci SORT ALTERNATIVE+ 

= TOTAL-CONSTRUCT | PARTIAL- CONSTRUCT 
= total-construct OP-NAME COMPONENTS* 

= partial- construct OP-NAME COMPONENTS+ 

= TOTAL-SELECT | PARTIAL- SELECT | SORT 
= total-select OP-NAME+ SORT 
= partial-select OP-NAME+ SORT 

= free-datatype DATATYPE -ITEMS 

= sort-gen SIG-ITEMS+ 

= var- items VAR-DECL+ 

= var-deci VAR+ SORT 

= local-var-axioms VAR-DECL+ AXIOM+ 

= axiom- items AXIOM+ 

= FORMULA 

= QUANTIFICATION | CONJUNCTION | DISJUNCTION 
I IMPLICATION I EQUIVALENCE | NEGATION | ATOM 
= quantification QUANTIFIER VAR-DECL+ FORMULA 
= universal | existential | unique -existential 
= conjunction F0RMULA+ 

= disjunction F0RMULA+ 

= implication FORMULA FORMULA 
= equivalence FORMULA FORMULA 
= negation FORMULA 

= TRUTH I PREDICATION | DEFINEDNESS 
I EXISTL-EQUATION | STRONG-EQUATION 
= true-atom | false-atom 
= predication PRED-SYMB TERMS 
= PRED-NAME | QUAL-PRED-NAME 
= qual-pred-name PRED-NAME PRED-TYPE 
= definedness TERM 
= existl-equation TERM TERM 
= strong- equation TERM TERM 

= terms TERM* 

= SIMPLE- ID I QUAL-VAR | APPLICATION 
I SORTED-TERM | CONDITIONAL 
= qual-var VAR SORT 
= application OP-SYMB TERMS 
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OP-SYMB : 

QUAL-OP-NAME : 

SORTED-TERM : 

CONDITIONAL : 

SORT : 

OP-NAME : 

PRED-NAME : 

VAR : 

SORT- ID : 

SIMPLE- ID : 

ID : 

MIX-TOKEN : 

TOKEN : 

BRACED- ID : 

BRACKET- ID : 

EMPTY-BRS : 

2.1.2 Subsorting 

SORT- ITEM : 

SUBSORT-DECL : 

ISO-DECL : 

SUBSORT-DEFN : 

ALTERNATIVE : 

SUBSORTS : 

ATOM : 

MEMBERSHIP : 

TERM : 

CAST : 



2.1.3 Structured 
SPEC : 



TRANSLATION 

RENAMING 

REDUCTION 

RESTRICTION 

HIDDEN 



= OP-NAME I QUAL-OP-NAME 
= qual-op-name OP-NAME OP-TYPE 
= sorted-term TERM SORT 
= conditional TERM FORMULA TERM 



= SORT- ID 
= ID 
= ID 

= SIMPLE- ID 

= WORDS 
= WORDS 

= id MIX-TOKEN+ 

= TOKEN I PLACE | BRACED- ID | BRACKET- ID | EMPTY-BRS 
= WORDS I DOT-WORDS I SIGNS I DIGIT | QUOTED-CHAR 
= braced-id ID 
= bracket -id ID 

= empty-braces | empty-brackets 



Specifications 

:= ... I SUBSORT-DECL | ISO-DECL | SUBSORT-DEFN 



:= subsort-deci SORT+ SORT 
:= iso-deci SORT+ 

:= subsort-defn SORT VAR SORT FORMULA 

:= ... I SUBSORTS 
:= subsorts SORT+ 

: = . . . I MEMBERSHIP 
:= membership TERM SORT 

: = . . . I CAST 
:= cast TERM SORT 



Specifications 

:= BASIC-SPEC I TRANSLATION | REDUCTION 
I UNION I EXTENSION | FREE-SPEC I LOCAL-SPEC 
I CLOSED-SPEC I SPEC-INST 

:= translation SPEC RENAMING 
:= renaming SYMB-MAP-ITEMS+ 

:= reduction SPEC RESTRICTION 
:= HIDDEN | REVEALED 
:= hidden SYMB-ITEMS+ 
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REVEALED : : = 

UNION ::= 
EXTENSION ::= 
FREE-SPEC ::= 
LOCAL-SPEC ::= 
CLOSED-SPEC ::= 

SPEC-DEFN ::= 
GENERICITY : := 
PARAMS : : = 
IMPORTED : : = 

SPEC-INST ::= 

FIT-ARG ::= 
FIT-SPEC ::= 
FIT-VIEW ::= 

VIEW-DEFN : : = 

VIEW-TYPE : : = 

SYMB-ITEMS : := 
SYMB-MAP- ITEMS : := 
SYMB-KIND ::= 

SYMB : : = 
QUAL-ID ::= 
TYPE : : = 
SYMB-MAP ::= 
SYMB-OR-MAP : := 

SPEC-NAME ::= 
VIEW-NAME : : = 

SORT- ID ::= 
COMP-SORT- ID ::= 
MIX-TOKEN ::= 
COMP-MIX-TOKEN : := 

2.1.4 Architectural 

ARCH-SPEC-DEFN : := 
ARCH-SPEC ::= 
BASIC-ARCH-SPEC : := 

UNIT-DECL-DEFN : := 
UNIT-DECL ::= 



revealed SYMB-MAP-ITEMS+ 

union SPEC+ 
extension SPEC+ 
free-spec SPEC 
local-spec SPEC SPEC 
closed-spec SPEC 

spec-defn SPEC-NAME GENERICITY SPEC 
genericity PARAMS IMPORTED 
params SPEC* 
imported SPEC* 

spec-inst SPEC-NAME FIT-ARG* 

FIT-SPEC I FIT-VIEW 
fit-spec SPEC SYMB-MAP-ITEMS* 
fit-view VIEW-NAME FIT-ARG* 

view-defn VIEW-NAME GENERICITY VIEW-TYPE 
SYMB-MAP-ITEMS* 
view-type SPEC SPEC 

symb- items SYMB-KIND SYMB+ 
symb-map- items SYMB-KIND SYMB-OR-MAP+ 
implicit I sorts-kind | ops-kind | preds-kind 

ID I QUAL-ID 
qual-id ID TYPE 
OP-TYPE I PRED-TYPE 
symb-map SYMB SYMB 
SYMB I SYMB-MAP 

SIMPLE- ID 
SIMPLE- ID 

... I COMP-SORT-ID 
comp-sort-id WORDS ID+ 

... I COMP-MIX-TOKEN 
comp-mix-token ID+ 

Specifications 

arch-spec-defn ARCH -SPEC -NAME ARCH-SPEC 
BASIC-ARCH-SPEC I ARCH -SPEC -NAME 
basic-arch-spec UNIT-DECL-DEFN+ RESULT-UNIT 

UNIT-DECL I UNIT-DEFN 

unit-deci UNIT-NAME UNIT-SPEC UNIT-IMPORTED 
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UNIT-IMPORTED : := unit -imported UNIT-TERM* 

UNIT-DEFN ::= unit-defn UNIT-NAME UNIT-EXPRESSION 



UNIT-SPEC-DEFN 

UNIT-SPEC 

ARCH-UNIT- SPEC 

CLOSED-UNIT-SPEC 

UNIT-TYPE 



unit-spec-defn SPEC-NAME UNIT-SPEC 
UNIT-TYPE I SPEC-NAME | ARCH-UNIT-SPEC 
CLOSED-UNIT-SPEC 
arch-unit-spec ARCH-SPEC 
closed-unit-spec UNIT-SPEC 
unit -type SPEC* SPEC 



RESULT-UNIT 

UNIT-EXPRESSION 

UNIT-BINDING 

UNIT-TERM 

UNIT-TRANSLATION 

UNIT-REDUCTION 

AMALGAMATION 

LOCAL-UNIT 

UNIT-APPL 

FIT-ARG-UNIT 



result-unit UNIT-EXPRESSION 
unit-expression UNIT-BINDING* UNIT-TERM 
unit-binding UNIT-NAME UNIT-SPEC 
UNIT-REDUCTION | UNIT-TRANSLATION | AMALGAMATION 
LOCAL-UNIT I UNIT-APPL 
unit-translation UNIT-TERM RENAMING 
unit-reduction UNIT-TERM RESTRICTION 
amalgamation UNIT-TERM+ 
local-unit UNIT-DEFN+ UNIT-TERM 
unit-appi UNIT-NAME FIT-ARG-UNIT* 
fit-arg-unit UNIT-TERM SYMB- MAP -ITEMS* 



ARCH-SPEC-NAME 

UNIT-NAME 



::= SIMPLE-ID 
::= SIMPLE- ID 



2.1.5 Specification Libraries 



LIB-DEFN 

LIB-ITEM 



= lib-defn LIB-NAME LIB-ITEM* 

= SPEC-DEFN I VIEW-DEFN 
I ARCH-SPEC-DEFN | UNIT-SPEC-DEFN 
I DOWNLOAD- ITEMS 



DOWNLOAD- ITEMS 
ITEM-NAME- OR-MAP 
ITEM-NAME-MAP 
ITEM-NAME 



download-items LIB-NAME ITEM-NAME- 0R-MAP+ 
ITEM-NAME | ITEM-NAME-MAP 
item-name-map ITEM-NAME ITEM-NAME 
SIMPLE- ID 



LIB-NAME 

LIB-VERSION 

VERSION-NUMBER 

LIB-ID 

DIRECT-LINK 

INDIRECT-LINK 



LIB-ID I LIB-VERSION 
lib-version LIB-ID VERS I ON- NUMBER 
vers ion- number NUMBER+ 

DIRECT-LINK | INDIRECT-LINK 
direct-link URL 
indirect -I ink PATH 




11:2.2 Abbreviated Grammar 



81 



2.2 Abbreviated Grammar 

This section provides an abbreviated grammar that dehnes the same (tree) 
language as the one in Sect. 2.1. It was obtained by eliminating each nonter- 
minal that corresponds to a single construct, when this nonterminal occurs 
only once as an alternative. 

As in Sect. 2.1, the following nonterminal symbols correspond to lexical 
syntax, and are left unspecihed in the abstract syntax: WORDS, DOT- WORDS, 
SIGNS, DIGIT, DIGITS, NUMBER, QUOTED-CHAR, PLACE, URL, and PATH. 



2.2.1 Basic Specifications 



BASIC-SPEC 
BASIC- ITEMS 



SIG-ITEMS 



SORT- ITEM 



= basic-spec BASIC-ITEMS* 

= SIG-ITEMS 

I free-datatype DATATYPE-DECL+ 

I sort-gen SIG-ITEMS+ 

I var- items VAR-DECL+ 

I local-var-axioms VAR-DECL+ F0RMULA+ 
I axiom- items F0RMULA+ 

= sort -items S0RT-ITEM+ 

I op- items 0P-ITEM+ 

I pred- items PRED-ITEM+ 

I datatype -items DATATYPE-DECL+ 

= sort-decl S0RT+ 



OP- ITEM 
OP-TYPE 



= op-decl 0P-NAME+ OP-TYPE OP-ATTR* 
I op-defn OP-NAME OP-HEAD TERM 
= total-op-type SORT-LIST SORT 
I partial-op-type SORT-LIST SORT 



SORT-LIST 



sort-list SORT* 



OP-ATTR 



assoc-op-attr | comm-op-attr | idem-op-attr 
unit-op-attr TERM 



OP-HEAD 



total-op-head ARG-DECL* SORT 
partial-op-head ARG-DECL* SORT 



ARG-DECL 



arg-decl VAR+ SORT 



PRED- ITEM 

PRED-TYPE 

PRED-HEAD 



pred-decl PRED-NAME+ PRED-TYPE 
pred-defn PRED-NAME PRED-HEAD FORMULA 
pred-type SORT-LIST 
pred-head ARG-DECL* 
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DATATYPE-DECL 

ALTERNATIVE 



COMPONENTS 



VAR-DECL 

FORMULA 



QUANTIFIER 

PRED-SYMB 

TERMS 

TERM 



OP-SYMB 

SORT 

OP-NAME 

PRED-NAME 

VAR 

SORT- ID 
ID 

SIMPLE-ID 

MIX-TOKEN 



TOKEN 



::= datatype-deci SORT ALTERNATIVE+ 

::= total-construct OP-NAME COMPONENTS* 

I partial- construct OP-NAME COMPONENTS+ 

::= total-select OP-NAME+ SORT 
I partial-select OP-NAME+ SORT 
I SORT 

::= var-deci VAR+ SORT 

::= quantification QUANTIFIER VAR-DECL+ FORMULA 
I conjunction F0RMULA+ 

I disjunction F0RMULA+ 

I implication FORMULA FORMULA 
I equivalence FORMULA FORMULA 
I negation FORMULA 
I true-atom | false-atom 
I predication PRED-SYMB TERMS 
I definedness TERM 
I existl-equation TERM TERM 
I strong- equation TERM TERM 

::= universal | existential | unique -existential 

::= PRED-NAME | qual-pred-name PRED-NAME PRED-TYPE 

::= terms TERM* 

::= SIMPLE- ID 

I qual-var VAR SORT 
I application OP-SYMB TERMS 
I sorted-term TERM SORT 
I conditional TERM FORMULA TERM 

::= OP-NAME | qual-op-name OP-NAME OP-TYPE 

::= SORT- ID 
: := ID 
: := ID 

::= SIMPLE- ID 

: : = WORDS 
: := id MIX-T0KEN+ 

: : = WORDS 
: : = TOKEN | PLACE 

I bracket- id ID | empty-brackets 
I braced-id ID | empty-braces 
::= WORDS I DOT-WORDS I SIGNS I DIGIT | QUOTED-CHAR 
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2.2.2 Subsorting 

SORT- ITEM : 

ALTERNATIVE : 

FORMULA : 

TERM : 

2.2.3 Structured 

SPEC : 



RENAMING 

RESTRICTION 

SPEC-DEFN 

GENERICITY 

PARAMS 

IMPORTED 

FIT-ARG 

VIEW-DEFN 

VIEW-TYPE 

SYMB-ITEMS 
SYMB-MAP- ITEMS 
SYMB-KIND 



Specifications 

I subsort -deci S0RT+ SORT 
I subsort -defn SORT VAR SORT FORMULA 
I iso-deci S0RT+ 



I subsorts S0RT+ 



I membership TERM SORT 



I cast TERM SORT 

Specifications 
:= BASIC-SPEC 

I translation SPEC RENAMING 
I reduction SPEC RESTRICTION 
I union SPEC+ 

I extension SPEC+ 

I free-spec SPEC 
I local-spec SPEC SPEC 
I closed-spec SPEC 
I spec-inst SPEC-NAME FIT-ARG* 

:= renaming SYMB-MAP- ITEMS+ 

:= hide SYMB-ITEMS+ 

I reveal SYMB-MAP-ITEMS+ 

:= spec-defn SPEC-NAME GENERICITY SPEC 
:= genericity PARAMS IMPORTED 
:= params SPEC* 

:= imported SPEC* 

:= fit-spec SPEC SYMB-MAP -ITEMS* 

I fit-view VIEW-NAME FIT-ARG* 

:= view-defn VIEW-NAME GENERICITY VIEW-TYPE 
SYMB-MAP- ITEMS* 

:= view-type SPEC SPEC 

:= symb-items SYMB-KIND SYMB+ 

:= symb-map-items SYMB-KIND SYMB-OR-MAP+ 

:= implicit I sorts-kind | ops-kind | preds-kind 
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SYMB 
TYPE 
SYMB -MAP 
SYMB-OR-MAP 

SPEC-NAME 

VIEW-NAME 

SORT- ID 
MIX-TOKEN 
COMP-SORT-ID 
COMP-MIX-TOKEN 



2.2.4 Architectural 

ARCH-SPEC-DEFN : := 

ARCH-SPEC ::= 

I 

UNIT-DECL-DEFN : := 

UNIT-DECL : : = 

UNIT- IMPORTED ::= 

UNIT-DEFN : : = 

UNIT-SPEC-DEFN : : = 

UNIT-SPEC ::= 

I 

UNIT-TYPE : : = 

RESULT-UNIT : : = 

UNIT-EXPRESSION : := 

UNIT-BINDING ::= 

UNIT-TERM : : = 

I 

I 

I 

I 

FIT-ARG-UNIT ::= 

ARCH-SPEC-NAME : := 

UNIT-NAME : : = 



ID I qual-id ID TYPE 
OP-TYPE I PRED-TYPE 
symb-map SYMB SYMB 
SYMB I SYMB-MAP 

SIMPLE- ID 
SIMPLE- ID 

... I COMP-SORT-ID 
... I COMP-MIX-TOKEN 
comp-sort-id WORDS ID+ 
comp-mix-token ID+ 



Specifications 

arch-spec-defn ARCH -SPEC -NAME ARCH-SPEC 
basic-arch-spec UNIT-DECL-DEFN+ RESULT-UNIT 
ARCH-SPEC-NAME 
UNIT-DECL I UNIT-DEFN 

unit-deci UNIT-NAME UNIT-SPEC UNIT-IMPORTED 

unit -imported UNIT-TERM* 

unit-defn UNIT-NAME UNIT-EXPRESSION 



unit-spec-defn SPEC-NAME UNIT-SPEC 

UNIT-TYPE I SPEC-NAME | arch-unit-spec ARCH-SPEC 

closed-unit-spec UNIT-SPEC 

unit -type SPEC* SPEC 

result-unit UNIT-EXPRESSION 
unit-expression UNIT-BINDING* UNIT-TERM 
unit-binding UNIT-NAME UNIT-SPEC 
unit -translation UNIT-TERM RENAMING 
unit -reduct ion UNIT-TERM RESTRICTION 
amalgamation UNIT-TERM+ 
local-unit UNIT-DEFN+ UNIT-TERM 
unit-appi UNIT-NAME FIT-ARG-UNIT* 
fit-arg-unit UNIT-TERM SYMB-MAP- ITEMS* 

SIMPLE- ID 
SIMPLE- ID 
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2.2.5 Specification Libraries 



LIB-DEFN 

LIB-ITEM 



ITEM-NAME- OR-MAP 
ITEM-NAME 



= lib-defn LIB-NAME LIB-ITEM* 

= SPEC-DEFN I VIEW-DEFN 
I ARCH-SPEC-DEFN | UNIT-SPEC-DEFN 
I download- items LIB-NAME ITEM-NAME-OR-MAP+ 

= ITEM-NAME | item-name-map ITEM-NAME ITEM-NAME 
= SIMPLE- ID 



LIB-NAME 

LIB-VERSION 

VERSION-NUMBER 

LIB-ID 



LIB-ID I LIB-VERSION 
lib-version LIB-ID VERS I ON- NUMBER 
vers ion- number NUMBER+ 
direct-link URL | indirect-link PATH 
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Concrete Syntax 



Section 3.1 gives a context-free grammar for the concrete syntax of Casl. 
The grammar is ambiguous; Sect. 3.2 explains various precedence rules for 
disambiguation, and the intended grouping of mixhx formulas and terms. 

The following meta-notation for context-free grammars is used not only for 
specifying the grouping syntax of Casl in this chapter, but also for specifying 
lexical symbols in Chaps. 4, and comments and annotations in Chap. 5. 

Nonterminal symbols are written as uppercase words, possibly hyphenated, 
e.g., SORT, BASIC-SPEC. 

Terminal symbols are written as either: 

• lowercase words, e.g. free, assoc; or 

• sequences of characters enclosed in double-quotes, e.g. " . or 

• sequences of characters enclosed in single quotes, e.g. ’ " ’ , ’ \ " . 
When sequences of characters cannot be confused with the meta-notation 
introduced below, the enclosing quotes are usually omitted. 

Sequenees of symbols are written with spaces between the symbols. The empty 
sequence is denoted by the reserved nonterminal symbol EMPTY. 

Optional symbols are underlined, e.g. end , j_. This is used also for the optional 
plural ‘s’ at the end of some lowercase words used as terminal symbols, 
e.g. sorts. 

Repetitions are indicated by ellipsis ‘ e.g. MIXFIX. . .MIXFIX denotes one 
or more occurrences of MIXFIX, and [SPEC] . . . [SPEC] denotes one or 
more occurrences of [SPEC] . Repetitions often involve separators, e.g. 
SORT, . . . , SORT denotes one or more occurrences of SORT separated by ‘ 
Alternative sequenees are separated by vertical bars, e.g. idem | unit TERM 
where the alternatives are idem and unit TERM. 

Produetion rules are written with the nonterminal symbol followed by :=’, 
followed by one or more alternatives. When a production extends a 
previously-given production for the same nonterminal symbol, this is in- 
dicated by writing ‘ ’ as its hrst alternative. 

Start symbols are not specihed. 
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The lexical symbols of Casl are given in Chap. 4. They consist of: 

• key words and symbols; 

• tokens: WORDS, DOT-WORDS, DIGIT, SIGNS, and QUOTED-CHAR; 

• literals: STRING, DIGITS, NUMBER, FRACTION, and FLOATING; 

• URL and PATH; and 

• COMMENT and ANNOTATION. 

The context-free grammar of Casl below treats these lexical symbols as termi- 
nal symbols. The language generated by this grammar is both LALR(l) and 
LL(1), and parsers can be generated from appropriate deterministic grammars 
using tools such as ML-yacc and Haskell combinator parsers. 

Lexical analysis for Casl is generally independent of the context-free pars- 
ing (apart from the recognition of NUMBER, URL and PATH, which may appear 
in libraries but not within individual specihcations). 

Context-free parsing of Casl specihcations according to the grammar in 
this section yields a parse tree where terms and formulas occurring in axioms 
and dehnitions have been grouped with respect to explicit parentheses and 
brackets, but where the intended applicative structure has not yet been rec- 
ognized. A further phase of mixfix grouping analysis is needed, dependent on 
the identihers declared in the specihcation and on parsing annotations, before 
the parse tree can be mapped to a complete abstract syntax tree. 

3.1.1 Basic Specifications 

BASIC-SPEC ::= BASIC- ITEMS. . .BASIC- ITEMS I {} 

BASIC-ITEMS ::= SIG-ITEMS 

I free types DATATYPE-DECL ; . . . ; DATATYPE-DECL y 

I generated types DATATYPE-DECL ; . . . ; DATATYPE-DECL 

I generated { SIG-ITEMS ... SIG-ITEMS } j_ 

I vars VAR-DECL ; . . . ; VAR-DECL 
I f orall VAR-DECL ; . . . ; VAR-DECL 

" . " FORMULA FORMULA j_ 

I " . " FORMULA FORMULA j_ 

SIG-ITEMS ::= sorts SORT-ITEM ;...; SORT-ITEM j_ 

I ops OP- ITEM ; . . . ; OP- ITEM j_ 

I preds PRED-ITEM ; . . . ; PRED-ITEM j_ 

I types DATATYPE-DECL ; . . . ; DATATYPE-DECL 

SORT-ITEM ::= SORT ,..., SORT 

OP-ITEM ::= OP-NAME ,..., OP-NAME : OP-TYPE 

I OP-NAME , . . . , OP-NAME : 

OP-TYPE , OP-ATTR , . . . , OP-ATTR 
I OP-NAME OP-HEAD = TERM 
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OP-TYPE 

OP-ATTR 
OP -HEAD 

ARG-DECL 

PRED-ITEM 

PRED-TYPE 

PRED-HEAD 

DATATYPE-DECL 

ALTERNATIVE 

COMPONENT 

VAR-DECL 

FORMULA 



QUANTIFIER 

TERMS 

TERM 



::= SORT SORT -> SORT | SORT 

I SORT SORT -> ? SORT | ? SORT 

: := assoc | comm | idem | unit TERM 

::= ( ARG-DECL ARG-DECL ) : SORT | : SORT 

I ( ARG-DECL ; . . . ; ARG-DECL ) : ? SORT | : ? SORT 

: : = VAR , . . . , VAR : SORT 

::= PRED-NAME PRED-NAME : PRED-TYPE 

I PRED-NAME PRED-HEAD <=> FORMULA 
I PRED-NAME <=> FORMULA 



: : = SORT * ... * SORT | ( ) 

::= ( ARG-DECL ;...; ARG-DECL ) 

: := SORT " : ALTERNATIVE " | " . . . " | " ALTERNATIVE 

::= OP-NAME ( COMPONENT ;...; COMPONENT ) 

I OP-NAME ( COMPONENT ; . . . ; COMPONENT ) ? 

I OP-NAME 



::= OP-NAME ,..., OP-NAME : SORT 
I OP-NAME , . . . , OP-NAME : ? SORT 
I SORT 

: : = VAR , . . . , VAR : SORT 



: := QUANTIFIER VAR-DECL ; . . . ; VAR-DECL " . " FORMULA 
FORMULA /\ FORMULA /\ . . . /\ FORMULA 
FORMULA \/ FORMULA \/ . . . \/ FORMULA 
FORMULA => FORMULA 
FORMULA if FORMULA 
FORMULA <=> FORMULA 
not FORMULA 
true I false 
def TERM 
TERM =e= TERM 
TERM = TERM 
( FORMULA ) 

MIXFIX. . .MIXFIX 



: := forall | exists | exists! 



: : = TERM , . . . , TERM 
: := MIXFIX. . .MIXFIX 
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MIXFIX ::= TOKEN | LITERAL | PLACE 

I QUAL-PRED-NAME | QUAL-VAR-NAME | QUAL-OP-NAME 
I TERM : SORT 

I TERM when FORMULA else TERM 
I ( TERMS ) 

I [ TERMS ] I [ ] 

I { TERMS } I { } 

QUAL-VAR-NAME : := ( var VAR : SORT ) 

QUAL-PRED-NAME ::= ( pred PRED-NAME : PRED-TYPE ) 

QUAL-OP-NAME : := ( op OP-NAME : OP-TYPE ) 

SORT ::= SORT-ID 

OP-NAME ::= ID 

PRED-NAME ::= ID 

VAR ::= SIMPLE-ID 

TOKEN ::= WORDS I DOT-WORDS I DIGIT | SIGNS 

I QUOTED-CHAR 

LITERAL ::= STRING I DIGITS I FRACTION | FLOATING 

PLACE : : = 



SORT- ID ::= WORDS 

SIMPLE- ID : := WORDS 

ID ::= MIX-TOKEN ... MIX-TOKEN 

MIX-TOKEN ::= TOKEN | PLACE 

I [ ID ] I [ ] 

I { ID } I { } 



3.1.2 Subsorting Specifications 

SORT- ITEM ::= ... 

I SORT , . . . , SORT < SORT 
I SORT = { VAR : SORT FORMULA } 
I SORT =. . .= SORT 



I sorts SORT , . . . , SORT 



ALTERNATIVE 
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FORMULA 

HIXFIX 



I TERM in SORT 
I TERM as SORT 



3.1.3 Structured Specifications 

SPEC ::= BASIC-SPEC 

I SPEC RENAMING 
I SPEC RESTRICTION 
I SPEC and SPEC and. . .and SPEC 
I SPEC then SPEC then. . .then SPEC 
I free GROUP-SPEC 
I local SPEC within SPEC 
I closed GROUP-SPEC 
I GROUP-SPEC 

GROUP-SPEC ::= { SPEC } 

I SPEC-NAME 

I SPEC-NAME [ FIT-ARG ] . . . [ FIT-ARG ] 

RENAMING ::= with SYMB -MAP -ITEMS SYMB -MAP -ITEMS 

RESTRICTION ::=hide SYMB-ITEMS ,..., SYMB-ITEMS 

I reveal SYMB -MAP -ITEMS , . . . , SYMB -MAP -ITEMS 

SPEC-DEFN ::= spec SPEC-NAME = SPEC ^ 

I spec SPEC-NAME SOME-GENERICS = SPEC end 

SOME-GENERICS : : = SOME-PARAMS I SOME-PARAMS SOME- IMPORTED 

SOME-PARAMS : : = [ SPEC ] . . . [ SPEC ] 

SOME-IMPORTED ::= given GROUP -SPEC ,..., GROUP-SPEC 

FIT-ARG ::= SPEC fit SYMB -MAP -ITEMS SYMB -MAP -ITEMS 

I SPEC 

I view VIEW-NAME 

I view VIEW-NAME [ FIT-ARG ] . . . [ FIT-ARG ] 

VIEW-DEFN : : = view VIEW-NAME : VIEW-TYPE ^ 

I view VIEW-NAME : VIEW-TYPE = 

SYMB-MAP-ITEMS , . . . , SYMB -MAP -ITEMS ^ 
I view VIEW-NAME SOME-GENERICS : VIEW-TYPE ^ 
I view VIEW-NAME SOME-GENERICS : VIEW-TYPE = 

SYMB-MAP-ITEMS , . . . , SYMB-MAP-ITEMS end 



VIEW-TYPE 



GROUP -SPEC to GROUP -SPEC 
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SYMB-ITEMS 



SYMB 

SOME-SYMB-KIND SYMB , . . . , SYMB 



SYMB-MAP- ITEMS 



SYMB-OR-MAP 

SOME-SYMB-KIND SYMB-OR-MAP , . . . , SYMB-OR-MAP 



SOME-SYMB-KIND 

SYMB 

TYPE 

SYMB-MAP 

SYMB-OR-MAP 

SPEC-NAME 

VIEW-NAME 

SORT- ID 

MIX-TOKEN 



sorts 1 


ops 1 


preds 


ID 1 ID 


: TYPE 




OP -TYPE 


1 PRED- 


TYPE 


SYMB 


" SYMB 




SYMB 1 SYMB-MAP 




SIMPLE-ID 

SIMPLE-ID 







I WORDS [ID , . . . , ID ] 
I [ ID , . . . , ID ] 



3.1.4 Architectural Specifications 



ARCH-SPEC-DEFN 

ARCH-SPEC 

GROUP-ARCH-SPEC 

BASIC-ARCH-SPEC 

UNIT-DECL-DEFN 

UNIT-DECL 

UNIT-DEFN 

UNIT-SPEC-DEFN 

UNIT-SPEC 



= arch spec ARCH -SPEC -NAME = ARCH-SPEC ^ 

= BASIC-ARCH-SPEC I GROUP -ARCH- SPEC 

= { ARCH-SPEC } I ARCH-SPEC-NAME 

= units UNIT-DECL-DEFN ; . . . ; UNIT-DECL-DEFN j_ 
result UNIT-EXPRESSION j_ 

= UNIT-DECL I UNIT-DEFN 

= UNIT-NAME : UNIT-SPEC 

given GROUP-UNIT-TERM , . . . , GROUP -UN IT- TERM 
I UNIT-NAME : UNIT-SPEC 

= UNIT-NAME = UNIT-EXPRESSION 

= unit spec SPEC-NAME = UNIT-SPEC ^ 

= GROUP -SPEC 

I GROUP-SPEC GROUP-SPEC -> GROUP-SPEC 

I arch spec GROUP -ARCH- SPEC 
I closed UNIT-SPEC 
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UNIT-EXPRESSION 



lambda UNIT-BINDING ; . . . ; 

UNIT-BINDING UNIT-TERM 
UNIT-TERM 



UNIT-BINDING 



UNIT-NAME : UNIT-SPEC 



UNIT-TERM 



= UNIT-TERM RENAMING 
I UNIT-TERM RESTRICTION 
I UNIT-TERM and... and UNIT-TERM 

I local UNIT-DEFN ; . . . ; UNIT-DEFN j_ within UNIT-TERM 
I GROUP-UNIT-TERM 



GROUP-UNIT-TERM : := { UNIT-TERM } 

I UNIT-NAME 

I UNIT-NAME [ FIT-ARG-UNIT ] . . . [ FIT-ARG-UNIT ] 



FIT-ARG-UNIT 



UNIT-TERM 

UNIT-TERM fit SYMB-MAP- ITEMS , . . . , SYMB- MAP -ITEMS 



ARCH-SPEC-NAME 

UNIT-NAME 



::= SIMPLE- ID 
::= SIMPLE- ID 



3.1.5 Specification Libraries 

LIB-DEFN ::= library LIB-NAME LIB-ITEM. . .LIB-ITEM 

LIB-ITEM ::=SPEC-DEFN | VIEW-DEFN 

I ARCH-SPEC-DEFN | UNIT-SPEC-DEFN 
I from LIB-NAME 

get ITEM-NAME-OR-MAP , . . . , ITEM-NAME- OR-MAP end 
ITEM-NAME-OR-MAP: := ITEM-NAME | ITEM-NAME ITEM-NAME 

ITEM-NAME ::= SIMPLE-ID 

LIB-NAME ::= LIB-ID | LIB- ID VERSION-NUMBER 

VERSION-NUMBER : := version NUMBER NUMBER 



3.2 Disambiguation 

The context-free grammar given in Sect. 3.1 for input syntax is quite ambigu- 
ous. This section explains various precedence rules for disambiguation, and 
the intended grouping of mixhx formulas and terms (which is to be recog- 
nized in a separate phase, dependent on the declared symbols and parsing 
annotations). 
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3.2.1 Precedence 

At the level of structured specifications, ambiguities of grouping are resolved 
as follows, in decreasing order of precedence: 

• ‘free’ and ‘closed’. 

• ‘with’, ‘reveal’, and ‘hide’. 

• ‘within’. 

• ‘and’. 

• ‘then’. 

At the level of architectural specifications, ambiguities of grouping in unit 
terms are resolved in the same way as for structured specifications. Moreover, 
a SPEC-NAME occurring as a UNIT-SPEC gives rise to just the SPEC-NAME itself 
in the abstract syntax tree, rather than a UNIT-TYPE with an empty list SPEC* 
of argument specifications. 

In BASIC-ITEMS, a fist of ‘. FORMULA ... . FORMULA’ extends as far to 
the right as possible. Within a FORMULA, the use of prefix and infix notation 
for the logical connectives gives rise to some potential ambiguities. These are 
resolved as follows, in decreasing order of precedence: 

• ‘not FORMULA’. 

• ‘FORMULA /\. . ./\ FORMULA’ and ‘FORMULA \/ ... \/ FORMULA’. These 
constructs may not be combined without explicit grouping. 

• The connectives ‘FORMULA => FORMULA’, ‘FORMULA if FORMULA’, 
‘FORMULA <=> FORMULA’. When repeated, ‘=>’ groups to the right, whereas 
‘if’ groups to the left; ‘<=>’ may not be repeated without explicit group- 
ing. These constructs may not be combined without explicit grouping. 

• ‘QUANTIFIER VAR-DECL; .... FORMULA’. The last FORMULA extends as far 
to the right as possible, e.g., ‘forall x:S . F => G’ is disambiguated as 
‘forall x:S . (F => G) ’, not as ‘ (forall x:S . F) => G’. 

Moreover, a quantification may be used on the right of a logical connective 
without grouping parentheses. For instance, 

‘F <=> exists x:s . G <=> H’ is parsed as 
‘F <=> (exists x:s . G <=> H)’. 

The declaration^ of infix, prefix, postfix, and general mixfix operation sym- 
bols may introduce further potential ambiguities, which are partially resolved 
as follows, in decreasing order of precedence (remaining ambiguities have to 
be eliminated by explicit use of grouping parentheses in terms, or by use of 
parsing annotations): 

• Ordinary function application ‘OP-SYMB (TERMS) ’. 

• Applications of postfix symbols. This extends to all mixfix symbols of the 

form ‘to • • • tn with to empty, and to sorted terms and casts. 

^ Declarations occurring anywhere in the enclosing list of basic items are taken into 
account when disambiguating the grouping of symbols in a term. 
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• Applications of prefix symbols. This extends to all mixfix symbols of the 

form To . . . with tn empty. 

• Applications of infix symbols. This extends to all mixfix symbols of the 

form To . . . with both and tn empty. Mixtures of different in- 

fix symbols and iterations of the same infix symbol have to be explicitly 
grouped - although the attribute of associativity implies a parsing annota- 
tion that allows iterated applications of that symbol to be written without 
grouping. 

• The conditional ‘TERM when FORMULA else TERM’. Iterations such as: 

Ti when Fi else T2 when F2 else T3 
are implicitly grouped to the right: 

Ti when Fi else (T2 when F2 else Ts) 

Various other techniques for allowing the omission of grouping parenthe- 
ses and/or list-separators in input (and display) are familiar from previous 
specification and programming languages, e.g., user-specified precedence (rel- 
ative or absolute). Moreover, not all parsers are expected to implement full 
mixfix notation. Casl therefore allows parsing annotations on (libraries of) 
specifications, to indicate the possible omission of grouping parentheses, and 
the degree of use of mixfix notation. (Such annotations are expected to apply 
uniformly to Casl sublanguages, and to most extensions.) Parsing annota- 
tions may even override the rules given above for the relative precedence of 
postfix, prefix, and infix symbols. See Sect. 5.2.3 for details of the available 
parsing annotations. 

3.2.2 Mixfix Grouping Analysis 

Mixfix grouping analysis of a specification should be equivalent to context- 
free parsing according to a derived grammar - obtained from the grammar in 
Sect. 3.1 by replacing the phrases involving MIXFIX with phrases determined 
(partly) by the declared symbols, as follows: 

FORMULA ::= ... | Q UAL -PRED- NAME 

I QUAL-PRED-NAME ( TERMS ) 

TERMS : : = TERM , . . . , TERM 

TERM ::= LITERAL | QUAL-VAR-NAME | QUAL-OP-NAME 
I QUAL-OP-NAME ( TERMS ) 

I TERM : SORT 
I TERM as SORT 

I TERM when FORMULA else TERM 
I ( TERM ) 

plus, for each declared variable or constant name id, 

I id 



TERM 
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plus, for each declared operation symbol id of positive arity, 

TERM \ id { TERMS ) 

plus, for each declared mixhx operation symbol ‘fo • • • tn (with and tn 

possibly empty), 

TERM \ to TERM . . . TERM tn 

plus, for each annotation ‘ 7 oli St bi b 2 , c, /’, 

TERM I 62 

(provided that b\ 62 is different from c) and 
TERM \ bi TERMS 62 

plus, for each declared predicate constant name id^ 

FORMULA \ id 

plus, for each declared predicate symbol id of positive arity, 

FORMULA ::= id ( TERMS ) 

plus, for each declared mixhx predicate symbol % . . . t^ (with to and tn 

possibly empty), 

FORMULA ::= to TERM . . . TERM tn 

It would be possible to obtain a hxed grammar for a sublanguage of Casl 
lacking mixhx notation in a similar way, using the appropriate kinds of ID 
in place of the declared ids above. (It may be convenient to obtain all these 
various grammars as extensions of a root grammar that is completely uncom- 
mitted about the notation used for applications, etc.) 

The context-free parsing during mixhx grouping analysis involves disam- 
biguation as determined by the general precedence rules for applications (see 
Sect. 3.2.1) and by any parsing annotations (see Sect. 5.2.3). 



3.2.3 Mixfix Identifiers 

An ID is well-formed only when no two adjacent MIX-TOKENs are TOKENS. Thus 
adjacent WORDS or SIGNS in an ID have to be separated by brackets or PLACES. 

Moreover, when an ID contains a TOKEN immediately followed by ‘ [ID] ’ or 
‘ [ID, . . . ,ID] ’, any further MIX-TOKENs in the same sequence of MIX-TOKENs 
must all be PLACES. This ensures that a list of identihers used to indicate a 
compound identiher can only be attached to the last token in an ID. 
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Lexical Symbols 



This chapter describes the lexical symbols of Casl. Section 4.1 lists the key 
words and signs, Sect. 4.2 specihes the tokens used to form identihers, and 
Sect. 4.3 describes the form of literal symbols for quoted characters, strings, 
and numbers. Finally, Sect. 4.4 gives a grammar for the simple URLs and paths 
used to identify libraries. The meta-notation used for grammars in this chapter 
is the same as in Chap. 3. The description of comments and annotations is 
deferred to Chap. 5. 

Spaces and other layout characters terminate lexical symbols, and are oth- 
erwise ignored, except in quoted characters and strings. The next lexical sym- 
bol recognized at each stage is as long as possible. The lexical syntax of Casl 
forms a regular language, and a lexical analyzer for Casl can be generated 
using ML-lex from a grammar given on the accompanying CD-ROM. Note 
that when a library name is expected, a different lexical analysis is required, 
see Sect. 4.4. Some Casl parsers are scannerless [8], which facilitates context- 
dependent analysis of lexical symbols. 

The character set for Casl specihcations is ISO Latin-1. However, specih- 
cations can always be input in the ASCII subset. 

For enhanced readability of specihcations, each lexical symbol has a display 
format for use with graphic screens and printers, involving various type styles 
(upright, italic, boldface, and small capitals) as well as common mathematical 
signs. (No restrictions are imposed concerning which font families are to be 
used for displaying Casl specihcations.) The display format for particular 
identihers can be determined by means of display annotations, as explained 
in Sect. 5.2.2. The input syntax of lexical symbols is easy to relate to their 
display format, and also sufficiently readable for use in (plain-text) e-mail 
messages. A DTp;X package implementing the display format is available [50]. 

4.1 Key Words and Signs 

The lexical symbols of Casl include various key words and signs that occur 
as terminal symbols in the context-free grammar in Chap. 3. Key words and 
signs that represent mathematical signs are displayed as such, when possible. 




98 



11:4 Lexical Symbols 



and those signs that are available in the ISO Latin- 1 character set may also 
be used for input. 

4.1.1 Key Words 

Key words are always written lowercase. The following key words are reserved, 
and are not available for use as complete identihers (nor as complete mixhx 
tokens in mixhx identihers) although they can be used as parts of tokens: 

and arch as axiom axioms closed def else end exists 
false fit forall free from generated get given hide 
if in lambda library local not op ops pred preds 
result reveal sort sorts spec then to true type types 
unit units var vars version view when with within 

The following key words are not reserved: 
assoc comm idem 

4.1.2 Key Signs 

The following key signs are reserved, and are not available for use as complete 
identihers (nor as mixhx tokens in mixhx identihers): 

: :? ::= = =><=> ^ . • | | -> \/ /\ 

The ISO Latin- 1 characters and are equivalent as key signs to the ASCII 

characters ‘not’ and ‘ respectively. The following key signs are not reserved: 

< * X -> ? ! 

The ISO Latin-1 key character ‘x’ is equivalent as a key sign to the ASCII 
character 

4.1.3 Display Format 

The following key words represent mathematical signs, and are displayed ac- 
cordingly when possible, as indicated below: 

forall exists not in lambda 

V 3 - G A 

The following key words are displayed in the same (italic) font as identihers 
when they occur in formulas, in attributes, or in alternatives of datatype 
declarations: 

true false not if when else assoc comm idem unit 
op ops pred preds sort sorts var vars 

Otherwise, key words are always displayed in a boldface font. 

The following key signs represent mathematical signs, and are displayed 
accordingly when possible, as indicated below: 

-> => <=> =e= . • l-> /\ \/ 
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4.2 Tokens 

This section defines the tokens used to form identifiers: words, signs, single 
digits, and quoted characters. Words are essentially alphanumeric sequences, 
allowing also some further characters. Signs are sequences of mathematical 
and punctuation characters. 



4.2.1 Words 

The lexical grammar for the tokens WORDS, DOT-WORDS, and DIGIT is as follows: 
WORDS : := WORD _ . . . _ WORD 

DOT-WORDS : : = " . " WORDS 



WORD 



::= WORD-CHAR ... WORD-CHAR 



WORD-CHAR ::= LETTER | | DIGIT 



LETTER 



= 


A 


1 


B 


1 


C 


1 


D 


1 


E 


1 


F 


1 


G 


1 


H 


1 


I 


1 


J 


1 


K 


1 


L 


1 


M 


1 


N 


1 


0 


1 


P 


1 


Q 


1 


R 


1 


S 


1 


T 


1 


U 


1 


V 


1 


W 


1 


X 


1 


Y 


1 


Z 


1 


a 


1 


b 


1 


c 


1 


d 


1 


e 


1 


f 


1 


g 


1 


h 


1 


i 


1 


j 


1 


k 


1 


1 


1 


m 


1 


n 


1 


0 


1 


P 


1 


q 


1 


r 


1 


s 


1 


t 


1 


u 


1 


V 


1 


w 


1 


X 


1 


y 


1 


z 


1 


A 


1 


A 


1 


A 


1 


A 


1 


A 


1 


A 


1 


iE 


1 


g 


1 


E 


1 


E 


1 


E 


1 


E 


1 


i 


1 


I 


1 


I 


1 


I 


1 


D 


1 


N 


1 


0 


1 


0 


1 


0 


1 


0 


1 


0 


1 


0 


1 


u 


1 


u 


1 


U 


1 


U 


1 


Y 


1 


P 


1 


iS 


1 


a 


1 


a 


1 


a 


1 


a 


1 


a 


1 


a 


1 


ae 


1 


? 


1 


e 


1 


e 


1 


e 


1 


e 


1 


i 


1 


1 


1 


i 


1 


i 


1 


5 


1 


n 


1 


6 


1 


6 


1 


6 


1 


6 


1 


0 


1 


0 


1 


u 


1 


u 


1 


u 


1 


ii 


1 


y 


1 


h 


1 


y 















DIGIT 



:= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8|9 



A WORDS must start with a LETTER, and must not be one of the reserved key 
words used in the context-free syntax in Sect. 4.1.1. Note that LETTER includes 
all the ISO Latin- 1 national and accented letters. 



4.2.2 Signs 

The lexical grammar for the token SIGNS is as follows: 
SIGNS : := SIGN . . . SIGN 

SIGN ::=+|-|*l/l\l&l=l<l> 

liUlx|-|£|©|±l1||§ 

I M M M • I I ° I - I M I "I" 

A SIGNS must not be one of the reserved signs: 

::?::= = =><=>-.•! I -> V A 
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These sequences of characters may however be used together with other char- 
acters in a SIGNS. For example, ‘==’, ‘:=’, and ‘IF are each recognized as a 
complete SIGNS. Note that identihers that start or hnish with a SIGNS need 
to be separated by (e.g.) a space from adjacent reserved signs: a sequence 
of characters such as ‘ # : ’is always recognized as a single symbol, whereas 
‘ # : ’is recognized as two symbols. 

A single character ‘<’, ‘x’, ‘?’, or ‘!’ is also recognized as a complete 

SIGNS, despite its use as a key sign as described in Sect. 4.1.2. 

Note that SIGN does not include the following ASCII signs: 

^ " 7o 

nor the ISO Latin-1 signs for general currency, yen, broken vertical bar, regis- 
tered trade mark, masculine and feminine ordinals, left and right angle quotes, 
fractions, soft hyphen, acute accent, cedilla, macron, and umlaut. 



4.2.3 Quoted Characters 

The lexical grammar for the token QUOTED -CHAR is as follows (where ‘ | . . . | ’ 
indicates evident alternatives that are omitted here for brevity): 

QUOTED-CHAR ::= CHAR 

CHAR ::= LETTER | DIGIT | SIGN 

I ; I , I M 7o I _ I " " 

I ( I ) I [ I ] I { I } 

I \n I \t I \r I \v I \b I \f 

I \a I \? I A"’ I I W 

I \000 I ... I \255 

I \x00 I ... I \xFF 

I \o000 I ... I \o377 



4.3 Literal Strings and Numbers 

Casl provides literal symbols for quoted strings and numbers. Their inter- 
pretation can be determined using annotations, as explained in Sect. 5.2.4. 
(Casl has no built-in datatypes, so literal symbols cannot have a default 
interpretation.) 

In contrast to the tokens described in Sect. 4.2, literal symbols abbreviate 
terms, and cannot be used as identihers. The lexical grammar of the symbols 
STRING, DIGITS, NUMBER, FRACTION, and FLOATING is a follows: 

STRING : : = ’ " ’ ’ " ’ I ’ " ’ CHAR . . . CHAR ’ " ’ 

DIGITS ::= DIGIT DIGIT ... DIGIT 



NUMBER 



::= DIGIT | DIGITS 
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FRACTION ::= NUMBER . NUMBER 

FLOATING ::= NUMBER "E" OPT-SIGN NUMBER 

I FRACTION "E" OPT-SIGN NUMBER 

OPT-SIGN ::= + I - I EMPTY 

NUMBER is recognized as a lexical symbol only where a VERS I ON -NUMBER is 
expected in specification libraries; elsewhere, a single digit is recognized as 
a DIGIT, and a sequence of two or more digits as a DIGITS (since only the 
former can be used as an identifier). 



4.4 URLs and Paths 

URL and PATH are recognized as lexical symbols only directly following the 
key words ‘library’ and ‘from’ in specification libraries. The following gram- 
mar provides a minimal syntax for URL: further forms may be recognized and 
supported. 

PATH-CHAR ::=A|...|Z|a|...|z|0|...|9 

I$l-I_l@|.|&l + I!|* 

I ”” I I ( I ) I , I : I ~ 

I 7, HEX-CHAR HEX-CHAR 

HEX-CHAR ::=A|...|F|a|...|f|0|...|9 

PATH-WORD ::= PATH-CHAR ... PATH-CHAR 
PATH : : = PATH-WORD / . . . / PATH-WORD 

URL : : = http : // PATH 

I ftp:// PATH 
I file:/// PATH 
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Comments and Annotations 



This chapter starts with a description of the common features of comments 
and annotations. Section 5.1 explains how comments are written. Section 5.2 
covers various kinds of annotations, including those used to provide literal 
syntax for numbers, strings, and lists. The meta-notation used for grammars 
in this chapter is the same as in Chap. 3. 

Comments and annotations can be used to provide auxiliary information 
that gets attached to the nodes of abstract syntax trees of Casl specihcations 
during parsing. They do not affect the semantics of specihcations, but may 
have signihcance for tool support. Comments may also be used to ignore parts 
of specihcations (so-called ‘commenting-out’). 

The general form of comments and annotations is similar: 

• they start with a percent character ‘X’; 

• their extent can be indicated by grouping brackets, terminated by ‘X’; 

• they have abbreviated forms for use at the end of the line (except for label 
annotations); and 

• they cannot be nested (except for commenting-outs, which are treated as 
blank space). 

Ordinary comments and annotations - collectively referred to here simply as 
annotations - can get attached to the following sorts of nodes in abstract 
syntax trees: 

• a SORT- ITEM, OP- ITEM, PRED-ITEM, or ALTERNATIVE; 

• a complete FORMULA (i.e., not part of a larger FORMULA or TERM) in an 
AXIOM, PRED-DEFN, or SUBSORT-DEFN; 

• a complete TERM (i.e., not part of a larger TERM) in an OP-DEFN; 

• a DATATYPE-DECL or SIG- ITEMS in a SORT-GEN or BASIC- ITEMS; 

• a SPEC, FIT-ARG, ARCH-SPEC, UNIT-DECL-DEFN, UNIT-TERM, LIB- ITEM, or 
LIB-DEFN. 

Such nodes can be formed by parsing text as the corresponding nonterminal 
symbols of the concrete syntax grammar given in Sect. 3.1 (they can also be 
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constructed by other tools). During parsing, the recognition of each of the 
above nodes may collect both preceding and trailing annotations. At hrst, a 
(possibly-empty) sequence of preceding annotations is collected. During the 
recognition of a node, any annotations not collected by inner nodes are kept 
as trailing annotations of the outer node. Finally, after the recognition of the 
outer node is complete, any further trailing annotations are collected - as long 
as they are on consecutive lines, i.e., without a blank line. ( Comment ed-out 
text is treated as blank space, so it may give the effect of a blank line.) After a 
blank line, preceding annotations for the next node that collects annotations 
may appear. (Final annotations of a library LIB-DEFN may extend to the end 
of the hie.) 

Thus annotations may occur anywhere between lexical tokens, but are only 
attached to the above sorts of nodes. The interpretation of some annotations 
is further explained in Sect. 5.2. 

The nonterminal symbols TEXT and TEXT- LINES are used only for specify- 
ing the form of comments and annotations, and are not themselves regarded 
as lexical symbols: 

TEXT ::= NOT-NEWLINE ... NOT-NEWLINE | EMPTY 

TEXT-LINE ::= TEXT NEWLINE 

TEXT-LINES ::= TEXT | TEXT-LINE TEXT-LINES 

NEWLINE denotes the character that indicates the start of a new line; 
NOT-NEWLINE denotes all the other printable ISO Latin-1 characters, together 
with the space and tab characters. 



5.1 Comments 



COMMENT 
COMMENT-LINE 
COMMENT-GROUP 
COMMENT- OUT 



COMMENT-LINE | COMMENT-GROUP I COMMENT-OUT 

7,7, TEXT-LINE 

7,{ TEXT-LINES }% 

7,[ TEXT-LINES ] % 



A single-line comment of the form ^yMext newline^ is equivalent to the 
grouped comment ‘‘yAtextY/d the latter form also allows multi-line comments. 
Arbitrary text is ‘commented out’ by writing ‘7, \_texf\ 7,’; commenting-out may 
be nested. 

Comments are generally displayed with the body in the same font as or- 
dinary informal text that might appear before and after a Casl specihcation. 
However, this may be overruled by explicit formatting instructions in the text 
of the comment. The preferred formatting of a part of a comment by different 
formatters is indicated using the following syntax (which is similar to that of 
display annotations, see Sect. 5.2.2): 

7,display text XHTML . . . XLATEX . . . 7oRTF . . . 
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at the end of a line, or, possibly over several lines: 

7, display ( text 7oHTML ... 7oLATEX ... 7oRTF ... )% 

Both the above indicate that the text is to be displayed according to the 
formatting instructions given for HTML, HTEpC, and RTF (which may be 
listed in any order, or omitted). Formatters for which there are no instructions 
should display the text exactly as input, preserving the line breaks of multi-line 
comments. 

If available, a smaller base font than normal may be used when displaying 
comments. The delimiters of comments are always to be displayed in boldface. 

Casl specihcation text within comments should be delimited by a brack- 
eted group^ of the form ‘7oCASL(. . to allow its appropriate display. The 
kind of Casl construct may be indicated by using a nonterminal symbol from 
the Casl abstract syntax (such as ‘ID’ or ‘TERM’, see Chap. 2) instead of 
‘CASL’. 



5.2 Annotations 

ANNOTATION ::= ANNOTATION-LINE | ANNOTATION- GROUP I LABEL 

ANNOTATION-LINE : := 7oWORDS TEXT-LINE 

ANNOTATION-GROUP : := DWORDS ( TEXT-LINES )% 

LABEL ::= %( TEXT-LINE )% 

In ANNOTATION-LINE and ANNOTATION-GROUP, spaces are not allowed before 
the WORDS, and an opening bracket ‘(’ directly following the WORDS distin- 
guishes an ANNOTATION-GROUP from an ANNOTATION-LINE. (The lexical to- 
ken WORDS is dehned in Sect. 4.2.1.) A single-line annotation of the form 
^7owords text newline^ is equivalent to ^7owords (text)7o\ 

Annotations at the beginning of a library (between the LIB-NAME and 
the hrst LIB- ITEM) apply globally to all its LIB-ITEMs, and to all libraries 
that download any of those items. Conflieting annotations that arise due to 
downloading from different remote libraries are simply ignored, whereas local 
annotations override conflicting annotations from remote libraries. Conflicting 
annotations within the same library are ignored as well. 

Each kind of annotation imposes restrictions on the syntax of its text. (It 
is envisaged that further kinds of annotations will be added later, but only 
with the same general form as indicated above.) 

Unless otherwise indicated below, annotations %words . . . ’ are to be dis- 
played in a smaller font than usual, when possible, and with the delimiters 
in boldface. Casl symbols in the body of the annotation are to be shown in 
their display format. Tools may suppress the display of particular kinds of 
annotations. 

^ The delimiters for Casl specification text in comments are similar to those used 
for multi- line annotations, see Sect. 5.2. 
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5.2.1 Label Annotations 

A label annotation is written (text -lines) 7o\ where text-lines is the label 
itself. For instance, in ‘7o(reverse-NeList)yo’ the label is ‘reverse-NeList’. 

A label annotation is normally attached to a complete FORMULA, although 
other constructs within a specihcation may be labelled as well. A label on an 
axiom is to be displayed flush with the right margin of the enclosing list of 
axioms, with the text-lines in the same font as used for text in comments. 

Labels are used by tools to reference parts of specihcations, and should 
therefore be unique at least within the same LIB- ITEM. 



5.2.2 Display Annotations 

A single-line display annotation ANNOTATION-LINE is written: 

7, display id 7oHTML . . . 7oLATEX . . . 7oRTF . . . 

It indicates that the identiher with input syntax id is to be displayed according 
to the formatting instructions given for HTML, 

DTeX, and RTF (which may be listed in any order, or omitted). When 
there are no instructions given for the language of the formatter being used, 
the identiher is displayed as its input syntax. 

The following example indicates that the identiher input as ‘div’ should be 
displayed as W’ by formatters that understand HTML or commands: 

7, display div 7oHTML fedivide; 7oLATEX \div 

Display annotations generalize to formatting mixhx notation by interpret- 
ing the place-holder ‘ ’ as such in the formatting instructions, e.g.: 

7odisplay( sum to 

7oHTML SUM<sub> <sup> 

7, LATEX \sum_{__}^{__} 

)7o 

The HTML level is assumed to be 4.0; the version of DTeX is assumed to 
be DTp;X2e, using the Casl package [50], in math mode. 

Display annotations may occur only at the beginning of libraries (between 
the LIB-NAME and the hrst LIB- ITEM), and apply globally. Display annotations 
for the same identiher are regarded as conhicting unless their formatting in- 
structions are identical or complementary, up to reordering. For displaying 
the annotation itself, only the input syntax and the display relevant to the 
formatter being used are to be shown. 



5.2.3 Parsing Annotations 

These annotations are to allow users to specify the precedence and associa- 
tivity of operation symbols. Their primary purpose is to allow the omission 
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of grouping parentheses in the input; but formatters may also exploit them 
to avoid superfluous parentheses in the display. Parsing annotations may oc- 
cur only at the beginning of libraries (between the LIB-NAME and the hrst 
LIB- ITEM), and apply globally. 



Precedence 

A single-line precedence annotation ANNOTATION-LINE is written: 

%prec iidi, ... , idn^ < iidn+i , . . . , 

Each idi is a mixhx identiher of the form ‘ . . . . . . ’. The relation 

{^^ 2 } specihes that the symbol id\ has lower priority (i.e., binds weaker) than 
the symbol id 2 . It is also possible to specify that mixhx identihers (of any form) 
are not allowed to be combined without explicit grouping parentheses. This is 
done using ‘o’ instead of ‘<’. In both cases, a precedence annotation involving 
groups of identihers abbreviates the collection of corresponding precedence 
annotations between each pair of identihers from the two groups. 

Two different precedence annotations for the same pair of identihers are 
regarded as conhicting. 

The precedence annotations determine a pre-order, which is obtained in 
the following way: 

1. Expand all precedence relations into binary relations: 

• from annotations of the form ‘7oprec < {^^ 2 }’ we get 

{(idi, ^^ 2 )}, and 

• from annotations of the form ‘7oprec <> {^^ 2 }’ we get 

{(idi, ^^ 2 ), (id2, idi)}. 

2. Take the union of all the expanded precedence relations thus obtained 
with the predehned precedences listed in Sect. 3.2. 

3. Take the rehexive transitive closure of this union. 

If two symbols occurring in a term or atomic formula are equivalent (i.e. 
related in both directions) or incomparable (i.e. related in no direction) in 
the precedence relation, their grouping has to be explicitly specihed by using 
parentheses. 



Associativity 

A single-line left-associativity annotation ANNOTATION-LINE is written: 

7oleft_assoc idi , • • • , idn 

The idi must be inhx operation symbols. Similarly for right-associativity an- 
notations. 

An associativity annotation involving a group of identihers abbreviates 
the collection of corresponding associativity annotations for each identiher in 
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the group. Left and right associativity annotations for the same identiher are 
regarded as conflicting. 

For example, declaring ‘ + ’ to be left associative means that 

is parsed as (^i+^ 2 )+fe while declaring it to be right associative leads to 
h+(t 2 +ts). If there is no associativity annotation for an inhx symbol, it is 
not allowed to repeat that symbol without explicit grouping using parenthe- 
ses. 

An associativity attribute ‘assoc’ for an operation (see Sect. 3.2) has the 
effect of an implicit associativity annotation. In contrast to explicit associa- 
tivity annotations, such an implicit associativity annotation is locals and only 
influences parsing of the surrounding specihcation (more precisely, only the 
items after the ‘assoc’ attribute) plus any specihcation importing the speci- 
hcation containing the attribute. If the operation with the assoc attribute is 
renamed, the local parsing annotation applies to the new name instead of the 
old one. 



5.2.4 Literal Annotations 

In this section, several annotations for operations are introduced that can 
be used to interpret the literal syntax for numbers and strings in Casl (see 
Sect. 4.3), and provide a literal syntax for lists. Literal annotations may oc- 
cur only at the beginning of libraries (between the LIB-NAME and the hrst 
LIB- ITEM), and apply globally. 



Literal Syntax for Numbers 

The annotation for declaring an operation to be used for concatenation of 
digits within a number is written ‘yoHumber / ’. 

The annotation has the effect that a DIGITS of the form di . . .dn (where 
n > 1 and each di is a DIGIT) is translated to the (abstract syntax of) the 
term /(/(... / (ti, ^ 2 ) ... , t^-i), t^), where ti is the abstract syntax tree for di. 
For example, to interpret DIGITS as decimal notation in connection with a 
particular datatype of integers, / would be a binary operation which, when 
applied to x and returns lOx + and the decimal digits would be dehned 
as the expected numbers from 0 to 9. 

Vice versa, an abstract syntax tree corresponding to a term of the above 
form which is maximal (i.e., it is not a sub-term of a larger term of the same 
form) is expected to be printed as di . . . . 

Different ‘yonumber’ annotations are regarded as conflicting. If there is 
no ‘yoHumber’ annotation, then a DIGITS is not recognized as a well-formed 
LITERAL. 

The annotation for declaring the operations used for evaluating the decimal 
point and the exponentiation ‘E’ within FRACTION or a FLOATING is written 
‘"/.floating /, g\ 
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The annotation has the effect that a FRACTION of the form ni.n2 (where 
each Ui is a NUMBER) is translated to the (abstract syntax of) the term /(ti, ^2), 
where ti is the abstract syntax tree for i = 1,2. 

Similarly, a FLOATING of the form ‘niEn2’ (where ni is a NUMBER or a 
FRACTION and U2 is of form OPT- SIGN NUMBER) is translated to the (abstract 
syntax of) the term ^^(^1,^2), where ti is the abstract syntax tree forn^, z = 1,2. 

Vice versa, an abstract syntax tree corresponding to a term of one of the 
above forms which is maximal (i.e., it is not a sub-term of a larger term of 
the same form) is expected to be printed as ni.n2 or niEn2^ respectively. 

Different ‘Xf loating’ annotations are regarded as conflicting. If there is no 
‘7of loating’ annotation, then neither a FRACTION nor a FLOATING is recognized 
as a well-formed LITERAL. 

Literal Syntax for Strings 

The annotation for declaring operations for the empty string and for concate- 
nation of a character with a string is written ‘Xstring c, / ’. 

The annotation has the effect that a STRING of the form ‘"ci . . 
(where n > 0 and each q is a CHAR) is translated to the (abstract syntax of) 
the term /(ti, / (t2, . . . /(t^, c) . . .)), where ti is the abstract syntax tree for 
the QUOTED - CHAR Ci ’ ’, or simply to c when n = 0 . 

Vice versa, an abstract syntax tree corresponding to a term of the above 
form which is maximal (i.e., it is not a sub-term of a larger term of the same 
form) is expected to be printed as ‘"ci . . . c^"’. 

Different ‘Xstring’ annotations are regarded as conflicting. If there is 
no ‘7oString’ annotation, then a STRING is not recognized as a well-formed 
LITERAL. 



Literal Syntax for Lists 

The annotation for declaring a macro for applying a binary function on a 

list of arguments is written ‘7olist bi 62 > c, f\ The symbol ‘‘bi 62’ is 

a mixhx identiher with a single place-holder, where b\ at least contains an 
open bracket (‘ [’ or T’) that must be matched by 62- This annotation can 

in particular be used to introduce a syntax for lists, e.g., ‘7olist [ ] , nil, 

cons’ allows the use of the notation ‘ [xi , . . . ,Xn'\ ’ for lists constructed using 
cons, starting from the empty list nil. 

A list of the form ‘‘bi t\, ... ,tn ^2 ’ (where n > 0 and each ti is a TERM) 
is translated to the (abstract syntax of) the term /(r^i, /('^2, • • • /('^n, c) . . .)), 
where Ui is the abstract syntax tree for or simply to c when n = 0. 

Vice versa, an abstract syntax tree corresponding to a term of the above 
form which is maximal (i.e., it is not a sub-term of a larger term of the same 
form) is expected to be printed as t\, ... ,tn 62’- 

Different ‘7olist’ annotations are regarded as conflicting when their mixhx 
identihers ‘‘bi 62’ are identical. 
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5.2.5 Semantic Annotations 

These annotations are used to express known (or presumed) features of the 
semantics of the specihcation, e.g., that an extension is ‘conservative’, or 
that certain formulas are consequences of the specihcation. Theorem-proving 
tools may interpret these annotations as proof obligations. Note, however, that 
the annotations do not affect the semantics of a specihcation, regardless of 
whether the specihcation has the indicated features or not. 

Implied Axioms 

The annotation for an implied axiom is written ‘7oiniplied’ (at the end of a 
line). 

In the context of basic specihcations the annotation 7oiniplied is used 
to characterize implicit or explicit axioms as logical consequences of the en- 
closing basic specihcation. 7oimplied may annotate a SORT- ITEM, OP- ITEM, 
PRED-ITEM, AXIOM, ALTERNATIVE, DATATYPE -DECL, or a BASIC-ITEMS consist- 
ing of a FREE-DATATYPE or SORT-GEN. 

Within a basic specification SP the annotations 7oimplied hold if the an- 
notation 7oimplies holds for the following structured specification: 

SPi then 7o implies SP 2 

Here, SPi consists of two parts: the hrst declares the whole signature of SP^ 
the second is SP without the items marked with 7oimplied. SP 2 is as SP 
without the non-7oimplied items, except that global variable declarations and 
parsing annotations (possibly arising from operation attributes) are kept. 

Extension Annotations 

All the remaining semantic annotations precede a specihcation SP' that fol- 
lows either: 

• a ‘then’ keyword within an extension - in which case, let SP be the part 
of the extension just up to, but excluding this occurrence of ‘then’; or 

• the equals sign within a SPEC-DEFN - in which case, let SP be the union 
of the imports, extended by the union of the parameters. 

Different semantic annotations at the same position are regarded as com- 
plementary. 

Conservative Extension 

The annotation for conservative extension is written ‘7ocons’. It expresses that 
SP' is a conservative extension of SP^ i.e. each SP-mode\ can be expanded 
to an {SP then SP')-mode\. 

Note that a model M' is an expansion of a model M iff M is a reduct 
of M'. 
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Monomorphic Extension 

The annotation for monomorphic extension is written ‘7oniono’. It expresses 
that SP' is a monomorphic extension of SP^ i.e. each model of SP can be 
expanded to a model of {SP then SP') that is unique up to isomorphism. 
Note that ‘7oniono’ is strictly stronger than the ‘7ocons’ annotation. 

Definitional Extension 

The annotation for dehnitional extension is written ‘7odef It expresses that 
SP' is a dehnitional extension of SP^ i.e. each model of SP can be uniquely 
expanded to a model of {SP then SP') (this implies a bijective correspon- 
dence between the two model classes). 

Note that ‘7odef ’ is strictly stronger than the ‘7omono’ annotation. 

Implied Extension 

The annotation for implied extension is written ‘7oimplies’. The annotation 
‘7oimplies’ is well- formed iff the signature of {SP then SP') is the signature 
of SP. A well- formed ‘7oimplies’ annotation holds iff the model class of {SP 
then SP') is the model class of SP. 

Note that ‘7oimplies’ is strictly stronger than the ‘7odef ’ annotation. 

5.2.6 Miscellaneous Annotations 

The annotations described in this section apply either to whole libraries or to 
the single library items that follow them. 

Authors 

An authors annotation is written: 

7oauthors namei <emaih> , namcn <emailn> 

at the end of a line, or, possibly over several lines: 

7oauthors( namei <emaili> , namcn <emailn> )7o 

It indicates the authors of the annotated construct. When a library item has 
no authors annotation, its authors are assumed to be the same as those of the 
enclosing library. The order of listing the authors is not constrained, and the 
listing of e-mail addresses is optional. 

Date 

A date annotation is written: 

7odate datei , . . . , datCn 

at the end of a line, or, possibly over several lines: 

7odate( datei, daten )7o 
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It indicates the latest modification date of the annotated construct. Any ad- 
ditional dates indicate some previous modification dates (possibly including 
the creation date). The order of listing the dates may be either increasing or 
decreasing. The format of the dates should be uniform and unambiguous. 
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Introduction 



This part of the Casl Reference Manual dehnes the formal semantics of the 
language Casl, as informally presented in the Casl Summary (Part I). Apart 
from this Introduction, which is partly devoted to dehning some basic nota- 
tion and explaining the style of the semantics, the structure of this document 
is deliberately almost identical to the structure of the Casl Summary to aid 
cross-reference. As in the Casl Summary, Chap. 2 deals with many-sorted 
basic specifications^ and Chap. 3 extends this by adding features for subsorted 
basic specifications. Chapter 4 provides structured specifications^ together with 
specification definitions^ instantiations^ and views. Chapter 5 summarizes ar- 
chitectural and unit specifications^ which, in contrast to structured specih- 
cations, prescribe the separate development of composable, reusable imple- 
mentation units. Finally, Chap. 6 considers specification libraries. There are 
two exceptions to the structural match between this document and the Casl 
Summary. One is in Chap. 4, where the subsections of Sect. 4.1 dehne many 
concepts and notations underlying the semantics of structured specihcations 
that were not mentioned in the Casl Summary. The other is in Chap. 5, 
where Sect. 5.6 presents a more precise analysis of the constructs considered 
in Sects. 5. 2-5. 5. 

The hrst section of each chapter dehnes the semantic concepts underlying 
the kind of specihcation concerned, with the remaining sections presenting 
the abstract syntax of the associated Casl language constructs and dehning 
their semantics. The abstract syntax is identical to that given in the Casl 
Summary; it is repeated here for ease of reference. 

Brief informal summaries of the main concepts and constructs precede each 
block of formal dehnitions. This material, which is in boxes (like this para- 
graph) is provided as a supplement to the formal material; since it deliber- 
ately glosses over the details, it should not be regarded as dehnitive. There 
is other informal explanatory text in between the dehnitions, but nothing 
that is likely to be mistaken for a dehnition. 
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1.1 Notation 

This section summarizes some of the basic notation used in the dehnitions 
below. 

Sets 

Set (A) is the set of all subsets of A, and FinSet{A) is the set of hnite subsets 
of A. If is a set then \A\ is the cardinality of A. unit denotes the singleton 
set {*}. 

Tuples 

Ai X X An is the set of n-tuples with jth component from Aj. Tuples 
are written like this: Sometimes the parentheses are omitted, 

especially when tuples are used as subscripts or superscripts. 

Sequenees 

FinSeq{A) is the set of hnite sequences of elements from A. Sequences are 
written like this: (ai, . . . ,an), where n > 0. (This notation is different from 
that used in the Casl Summary and the abstract syntax, where FinSeq{A) 
is written A* and (ai, . . . , a^) is written ai . . . Un.) If re = (ai, . . . , a^) then 
\w\ = n. 

Funetions 

A ^ B is the set of partial functions from Ato B. Dom{f) C A is the domain 
of f : A ^ B. A ^ B is the set of total functions from A to B. Any total 
function f : A ^ B can also be regarded as a partial function f : A' ^ B 
for any A' 5 A, and any partial function f : A ^ B is a total function 
/ : Dom{f) B. Functions are written like this: {ai ^ 6i, . . . ,a^ ^ 6^}, 
where n>0, or{x^x + 3 |xG Nat}. We use the notation f{x) for 
application of a function / to an argument x. Sometimes the parentheses are 
omitted, for instance when x is a tuple or a sequence. The graph of a function 
f : A ^ B is the set of pairs graph{f) = {(x,/(x)) | x G Dom{f)} and the 
kernel of / is ker{f) = {{x^y) | x, ^ G Dom{f) and f{x) = f{y)}. When / is 
an indexed family (a function from an index set to a domain of elements) we 

write fx instead of f{x). A^ B is the set of hnite maps (i.e. partial functions 
with hnite domain) from A to B. 

Union and 0 

We use union (U) to combine semantic objects of various kinds, with the 
evident interpretation (e.g. component-wise union for tuples and point-wise 
union for functions, that is (/ U g){x) = f{x) U g{x) if f and g are set- valued 
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functions such that Dom{f) = Dom{g)). More generally, for any set-valued 
functions / and g we take 



(fUg){x) 



f(x) U q(x) if X G Dom(f) H Dom(q) 
f{x) if X G Dom{f)\Dom{g) 

g{x) if X G Dom{g) \ Dom{f) 

undehned otherwise 



which gives Dom(fUg) = Dom{f)U Dom{g) . Similarly, 0 is used for the empty 
object of various kinds (e.g. empty signature, empty function). If n = 0 then 
AiU ' ' ' U An denotes 0. 



Disjoint union 

l±) 5 is the disjoint union of A and B. Injection from A and B to A B is 
implicit. 

Given a union of syntactic categories, as in 
OP-TYPE ::= TOTAL-OP-TYPE | PARTIAL -OP -TYPE 

we distinguish between a G TOTAL- OP-TYPE (resp. a G PARTIAL- OP-TYPE) 
and a G OP-TYPE by writing the latter as ‘a qua OP-TYPE’. The syntactic 
categories in question are always disjoint, with different constructors being 
used to form their phrases (in this case, the constructors are total-op-type 
and partial-op-type). 

Function completion 

We sometimes need to ‘complete’ a function / with Dom{f) C S to give 
a function with domain S by mapping values in S \ Dom{f) to an appro- 
priate neutral value. In particular, if / is a set-valued function, we dehne 
complete{f^ S) = fU{x\-^^\x^S \ Dom{f)}. 

Categories 

Some elementary category theory is used in places. A suitable introduction is 
[52]. The category of sets is denoted Set and the (quasi) category of categories 
is denoted CAT ^ . We use the notation fog for (applicative order) composition 
of morphisms in a category. In Set this gives (/ o g){x) = f{g{x)). The class 
of objects of a category C is written \C\ and the identity morphism on A is 
written idA- 

^ There are foundational problems connected with the use of CAT - see [27] for 
how to solve them. 
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Semantic domains 

We define various semantic domains below. By convention, semantic domains 
containing ‘syntactic’ objects (e.g. Signature) are in italics and semantic do- 
mains containing ‘semantic’ objects (e.g. Model) are in boldface. Here is an 
example of a domain of ‘syntactic’ objects: 

(re, 5) or ws G FunProfile = FinSeq(Sort) x Sort 

This defines the set FunProfile as the set of pairs having finite sequences 
of elements from Sort as first component and elements of Sort as second 
component. The metavariable ws ranges over elements of FunProfile. When 
we need to refer to the components of the pair we use the notation (re, 5) 
instead, so w ranges over elements of FinSeq{Sort) and s ranges over elements 
of Sort. 

Validity 

Typically, semantic domains are constructed from ‘more basic’ domains to- 
gether with some well-formedness requirements. Then a valid object is a value 
in the given set that satisfies the given requirements. Here is an example: 

X e Variables = Sort ^ FinSet{ Var) 

Requirements on an /S-sorted set of variables X: 

• Dom{X) = S 

• for all 5, 5' G /S' such that 5 7^ 5', Xg H Xg' = 0 . 

This says that a ‘set of variables’ is a finite map taking elements of Sort to 
finite subsets of Tar, while a ‘valid S'-sorted set of variables’ is a finite map 
of this kind that satisfies the two requirements given. Often, as in this case, 
validity of an object is relative to some other (valid) object, here a set S of 
sorts. We will tacitly require all objects that arise in defining the semantics 
of Casl phrases to be valid. 

Abstract syntax 

For an introduction to the form of grammar used to define the abstract syntax 
of language constructs, see Chap. 11 : 2 , which also contains the abstract syntax 
of the entire Casl specification language. 



1.2 Static Semantics and Model Semantics 

The semantics of language constructs is given in two parts. The static seman- 
tics checks well-formedness of phrases of the abstract syntax and produces a 
‘syntactic’ object as result, failing to produce any result for ill- formed phrases. 
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For example, for a many-sorted basic specification (see Chap. 2) the static 
semantics yields an enrichment containing the sorts, function symbols, predi- 
cate symbols and axioms that belong to the specification. A judgement of the 
static semantics has the following form: context h phrase > result. The model 
semantics provides the corresponding model-theoretic part of the semantics, 
and is intended to be applied only to phrases that are well-formed according 
to the static semantics. For a basic specification, the model semantics yields a 
class of models. A judgement of the model semantics has the following form: 
context h phrase ^ result. 

A statically well-formed phrase may still be ill-formed according to the 
model semantics, and then no result is produced. This can never happen 
in the semantics of basic constructs but it can happen in the semantics of 
structured specifications and architectural specifications. 



1.3 Semantic Rules 

The judgements of the static semantics and model semantics are defined in- 
ductively by means of rules in the style of Natural Semantics [30]. For each 
phrase class we give a group of rules defining the semantics of the constructs 
in that class. The group is preceded by a specification of the ‘type’ of the 
judgement (s) being defined. This is followed by pre-conditions on the ‘inputs’ 
to the judgement (s) which, if satisfied, guarantee that the ‘outputs’ satisfy 
the given post-conditions. Each of the rules should ensure that this is the 
case. For example, here is the section of the semantics for the phrase class 
AXIOM- ITEMS from Sect. 2.5 below, for which there is just one rule. 



A, X h AXIOM- ITEMS > ^ 

X is required to be a valid set of variables over the sorts of X. is a 
set of X-sentences. 

X,X h AXIOMi > V'l ••• X,X h AXIOMn 
X, X h axiom-items AXIOMi . . . AXIOM^ > {V^i, . . . , 'ifjn} 

The ‘type’ of the judgement is X,X h AXIOM-ITEMS > Intuitively, this 
says that in the local environment X with declared variables X, a phrase 
AXIOM- ITEMS yields a set ^ of sentences. The pre-condition on the ‘inputs’ 
is the requirement that X be a valid set of variables over the sorts of X. 
(The requirement that X itself be valid is implicit - use of a metavariable 
always refers to a valid object of the relevant kind.) The post-condition on 
the ‘output’ is the assertion that W will then be a set of X-sentences. It is easy 
to see that the given rule satisfies the pre/post-condition: if X,X satisfy the 
pre-condition then the post-condition associated with AXIOM guarantees that 
all of ^01, . . . , ipri will be X-sentences, and W here is just {V^i, . . . , '0^}. 
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Rules in the static semantics and model semantics have the form 

0^1 • • • (Xfi 

p 

where the conclusion is a judgement and each premise aj is either a judge- 
ment or a side-condition. When all the judgements occurring in all rules are 
positive (i.e. not negated) then the rules unambiguously dehne a family of 
relations via the usual notion of derivation tree, or equivalently as the small- 
est family of relations that is closed under the rules. Conclusions are always 
positive but there are situations in which negative premises are convenient. 
These are potentially problematic for at least two reasons: hrst, there may be 
no family of relations that is closed under the rules; second, there may be no 
smallest family of relations that is closed under the rules. It follows that care is 
required in situations where the natural choice of rules would involve negative 
premises. One way out is to simultaneously dehne a relation and its negation 
using rules with positive premises only, as in Sect. 2.1.4 below. Another is via 
the use of stratihcation to ensure the absence of dangerous circularities, cf. 
‘negation by failure’ in logic programming [53], as in Sect. 2.5.3. See [19] for 
further discussion. 

When a syntactic category C is dehned as the disjoint union of other 
syntactic categories Ci, . . . ,(7^^, rules that merely translate a judgement for 
Cl etc. to a judgement for C are elided. Here is a schematic example of the 
kind of rules that are elided, for the static semantics: 

context h phrase > result 
context h phrase qua C > result 

Whenever such a rule is elided there will be a statement to this effect in the 
rule’s place. 



1.4 Institution Independence 

Casl is the heart of a family of languages. Sublanguages of Casl are obtained 
by imposing syntactic or semantic restrictions, while extensions of Casl sup- 
port various paradigms and applications. 

The features of Casl for dehning structured specihcations, architectural 
specihcations and specihcation libraries do not depend on the details of the 
features for basic specihcations, so this part of the design is orthogonal to the 
rest. As a consequence, sublanguages and extensions of Casl can be dehned 
by restricting or extending the language of basic specihcations without the 
need to reconsider or change the rest of the language. On a semantic level, 
this is rehected by giving the semantics in an ‘institution independent’ style. 
The semantics of basic specihcations with subsorts dehnes an institution [20] 
for Casl- actually, a variant of the notion of institution called an institution 
with symbols [39] - and the rest of the semantics is based on an arbitrary 
institution (with symbols). See Sect. 4.1 for more details. 
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Basic Specification Semantics 



A basic specification describes an extension A to the local environment A, 
together with a set of sentences over E U A. This describes in turn the class 
of all models over E U A that satisfy those sentences. 

To make this precise, Sect. 2.1 dehnes the underlying concepts, and the 
remaining sections cover the language constructs provided by Casl for use in 
such specihcations, giving their abstract syntax and dehning their interpreta- 
tion. Consideration of the extra features concerned with subsorts is deferred 
to Chap. 3. 



2.1 Basic Concepts 

The concepts underlying basic specihcations in Casl are those involved in 

dehning an institution [20] for Casl. The following elements are required: 

• a category Sig of signatures A, with signature morphisms a : E ^ E'; 

• a (contravariant) functor Mod : Sig^^ ^ CAT giving for each signature 
E a category Mod(A) of models over A, with homomorphisms between 
them, and for each signature morphism a : E ^ E' d, reduct functor 
Mod(cr) : Mod(A') ^ Mod(A) (usually written .|cr) translating models 
and homomorphisms over E' to models and homomorphisms over A; 

• a functor Sen : Sig ^ Set giving for each signature E a set Sen(A) of 
sentences (or axioms) over A, and for each signature morphism a : E ^ E' 
a translation function Sen(cr), usually written cr(.), taking A-sentences to 
A'-sentences; and 

• a relation ^ of satisfaction between models and sentences over the same 
signature. 

Satisfaction is required to be compatible with reducts of models and transla- 
tion of sentences: for all ip G Sen(A) and M' G Mod(A'), 
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(Additional structure is required for Chaps. 4 and 5, including a functor |.| : 
Sig ^ Set with certain properties which determines the set of signature 
symbols of any signature.) 

The rest of this section dehnes the signatures, models, sentences, and sat- 
isfaction relation that underlie many-sorted basic specihcations. 



2.1.1 Signatures 



A many-sorted signature U consists of: a set of sorts; separate families of 
sets of total and partial funetion symbols^ indexed by funetion profile (a 
sequence of argument sorts and a result sort - eonstants are treated as 
functions with no arguments); and a family of sets of predieate symbols^ 
indexed by predieate profile (a sequence of argument sorts). Constants and 
functions are also referred to as operations. 

The internal structure of identihers used to identify sorts, functions and 
predicates is insignihcant for the semantics of basic specihcations, see Sect. 2.6. 
Following the order of presentation in the Casl Summary, we therefore leave 
this unspecihed for now, promising that there will be no circularity when the 
dehnitions of the sets Sort^ FunName and PredName are eventually provided: 

s G Sort 
f G FunName 
p G PredName 

(In Sect. 2.3 the internal structure of sorts will be dehned as SORT- ID and the 
internal structure of function and predicate symbols will be dehned as ID.) 

S G SortSet = FinSet{Sort) 

(re, 5 ) or ws G FunProfile = FinSeq(Sort) x Sort 

TP ^ PF G FunSet = FunProfile FinSet {FunName) 

w G PredProfile = FinSeq{Sort) 

P G PredSet = PredProfile FinSet {PredName) 

For a set of total function symbols TP over S it is required that Dom{ TP) = 
FinSeq{S) x S and that TF^s 0 for only hnitely many function prohles 
ws G FinSeq{S) x S', and similarly for a set of partial function symbols PF. For 
a set of predicate symbols P over S it is required that Dom{P) = FinSeq{S) 
and that 7 ^ 0 for only hnitely many predicate prohles w G FinSeq{S). 

{S, TF,PF,P) 

or A G Signature = 

SortSet X FunSet x FunSet x PredSet 
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Requirements on a signature (/S', TF, PF^P): 

• TF and PF are sets of total resp. partial function symbols over S 

• P is a set of predicate symbols over S 

• for all ws G FinSeq{S) x S', TF H PF = 0 

(An alternative to the use of the separate signature components TF and PF 
would be a single component F with a totality marker, so e.g. F : FunProfile x 
{total, partial} ^ FinSet{FunName) cf. [38, 67].) 

Later we will need signature extensions as well. These are signature frag- 
ments that are interpreted relative to some other signature. First we dehne 
signature fragments. 

(S', TF^ PF^P) G SigFragment = 

SortSet X FunSet x FunSet x PredSet 

These are simply signatures minus the validity requirements. 

Union of signature fragments is dehned as follows: 

(S', PP, PP, P) U (S", PP', PP', P') = 

reeoneile{S U S", eomplete{TF U TF' ^FinSeq{S") x S'"), 
eomplete{PF U PP', FinSeq{S") x S'"), 
eomplete{P U P', FinSeq{S"))) 



where 

S'" = S' U S'' U sorts {Dom{TF)) U sorts {Dom{PF)) U sorts {Dom{P)) 

U sorts{Dom{TF')) U sorts {Dom{PF')) U sorts {Dom{P')) 



and 

reeoneile{S^ TF ^ PF ^ P) = (S', TF^{ws ^ PFws\TFujs \ ws G Pom(PP)},P). 

Here, sorts(T) is the set of sorts appearing in function/predicate prohles in P. 
The idea of this dehnition is to give the same result as if signature fragments 
were dehned as sets of individual sort /function/predicate declarations. Note 
that any signature is also a signature fragment so this dehnition also dehnes 
the union of two signatures as well as the union of a signature and a signature 
fragment. According to this dehnition, the union of two signatures will always 
be a signature with S" = S VJ S' . When a function name is declared as both 
partial and total, the reeoneile function causes it to be regarded as total in 
the union, as required in Sects. 1:2. 3. 2 and 1:4. 2. 3. 

(/S', PP, PP, P) or Z\ G Extension = SigFragment 

A signature extension relative to a signature A is a signature fragment A 
such that E U A (the ‘‘target” of the signature extension) is a signature. This 
guarantees that all the sorts used for function and predicate prohles in A are 
declared in either A or E. 
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Proposition 2.1. If A and A! are signature extensions relative to U then 
AVJ A' is a signature extension relative to U. 

Proof. Straightforward. □ 

A signature A is a subsignature of a signature U' if there is some extension 
A relative to U such that U' = UU A. Note that this allows a function name 
to be a partial function symbol in U but a total function symbol in U' . 

Symbols used to identify sorts, operations, and predicates may be overloaded. 
For example, it is possible that / G and / G TF^s' for ws ^ ws' ^ as 

well as f e S. To ensure that there is no ambiguity in sentences at this level, 
function symbols / and predicate symbols p are always qualified by prohles 
when used, written f^s and p^j respectively. (The language considered later 
in this chapter allows the omission of such qualihcations when they are 
unambiguously determined by the context.) 



fws ^ QualFunName = FunName x FunProfile 
Pw ^ QualPredN ame = PredName x PredProfile 

Requirements on a qualihed function name f^js over U = (F, TF, PF^P): 

• ws ^ FinSeq{S) x S 

• / G TF U PF^s 

Requirements on a qualihed predicate name p^j over U = (F, TF ^ PF^P): 

• we FinSeq{S) 

• Pw 

Following [39], Chaps. 4 and 5 below require that we dehne a set SigSym 
of signature symbols and a function |.| taking any signature to the set of 
signature symbols it contains (in fact we need a functor |.| : Sig ^ Set having 
certain properties, see Prop. 2.4 below). Signature symbols are essentially just 
qualihed function/predicate names together with sort names. 

SigSym = 

s G Sort l±) 

fws G QualFunName l±) 

Pw G QualPredName 

If A = (F, TF,PF,P), we dehne |F| C SigSym as follows: 

|F| = F U {fws I ws G FinSeq{S) x F, / G TF^^ U PF ws} 

C {pw I ^ FinSeq{S),p G Pw} 



A many-sorted signature morphism a : N ^ N' maps symbols in E to 
symbols in Ah A partial function symbol may be mapped to a total function 
symbol, but not vice versa. 




111:2.1 Basic Concepts 127 



G SMap = Sort Sort 

^TF ^ TFMap = FunProfile {FunName ^ FunName) 

G PFMap = FunProfile [FunName ^ FunName) 

G PMap = PredProfile {PredName ^ PredName) 

: N ^ N' 

or G : N ^ N' ^ SignatureMorphism = 

Signature 

xSMap X TFMap x PFMap x PMap 
X Signature 

Requirements on a signature morphism (a^, : (/S', TF , PF , P) 

{S', TF',PF',P'): 

• : S' ^ S" 

• = Dom{G^^) = FinSeq(S) x S' 

• for all G FinSeq{S) x S': 

- crjg : TFujs '^^a^(ws) 

- G^g : PFws ^ ^^a^(ws) 

• Dom{G^) = FinSeq{S) 

• for all w G FinSeq{S), ^ 

where, for w = {s\, . . . , Sn)^ g^{w) = (a^ (si ),..., (7^(5^)) and cr^(re, 5 ) = 
{g^ { w) , G^ {s)) . If P is a subsignature of N' , we write N ^ N' for the ev- 
ident signature morphism. Such a signature morphism is called a signature 
inelusion. Note that a signature extension A relative to N can be viewed 
more abstractly as the signature inclusion N ^ P U Z\. However, informa- 
tion about any re-declaration in A of symbols in N is lost by this abstraction. 
Therefore A is kept explicitly together with the signature inclusion in Chap. 4 . 
li G : N ^ N' and p : N' ^ N" are signature morphisms, where g = 
p = {p^ , p~^^ , p^^ , p^) and P = {S,TF,PF,P), then the 
composition poG : N ^ N" is the signature morphism (( 5 ^, , S^) where 

= p^ O G^, 

W = {ws 1-^ pJsGs) o I ws e FinSeq{S) x S}, 

,JPF = {ws ^ ° I ^ FinSeq{S) x S}, 

(JP = {w 1-^ o I w e FinSeq{S)} 

Identity morphisms idjj are obvious. 

Proposition 2 . 2 . The eomposition of signature morphisms does indeed yield 
a signature morphism. 

Proof. In the dehnition of , Pls(^ws)^ha^(ws) ^ function because 
PF'c^s(^ws) ~ proof is straightforward. □ 
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Proposition 2.3. Signatures and signature morphisms form a finitely eoeom- 
plete eategory, Sig. 



Proof. It is easy to see that Sig is a category. Regarding finite cocompleteness, 
see [38] for a more general result. □ 

If (7 : ^ is a signature morphism, where a = (a^, a^), U = 

(5, TF,PF,P) and = (5", TF', PF', P'). then the function |a| : |F| ^ |F'| 
is dehned as follows: 



|cr|(5) = < 7 ^( 5 ) for all 5 G F 




0^wlU)crHwa) for f e TF 
for / e 

for all ws G FinSeq{S) x S 



\<^\{Pw) = 

for all w G FinSeq{S) and p ^ P^ 



Proposition 2.4. |.| : Sig ^ Set is a faithful funetor. 

Proof. It is easy to see that |.| is a functor. Faithfulness is also obvious: |(7| 
(together with the partiality data in U and U') carries no less information 
than a : U ^ U' . □ 

Proposition 2.5. A signature morphism a : E ^ E' is a signature inelusion 
iff \(j\ is an inelusion of \E\ into \E'\. 

Proof. Straightforward. It is essential that in a signature inclusion a : E ^ E' ^ 
a function name may be a partial function symbol in E but a total function 
symbol in Fb □ 



2.1.2 Models 

For a many-sorted signature F, a many-sorted model M G Mod(F) assigns 
a non-empty earrier set to each sort in F, a partial resp. total funetion to 
each partial resp. total function symbol, and a predieate to each predicate 
symbol. Requiring carriers to be non-empty simplihes deduction [21] and 
will allow axioms in specihcations to be implicitly universally quant ihed, see 
Sect. 2.4. 



S^{s) or G Carrier = the class of all sets 
pM ^ Carriers = Sort ^ Carrier 
^ws (/) ^ PartialFun = the class of all partial functions 

pM ^ PartialFuns = FunProfile {FunName ^ PartialFun) 
Pff (p) or p^ G Pred = the class of all predicates 

pM ^ Preds = PredProfile {PredName ^ Pred) 

pM pM'^ 

or M G Model = Carriers x PartialFuns x Preds 
M e ModelClass = 5'et(Model) 
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Requirements on a i7-model M = (5^, for = (5, TF, PF, P): 

• Dom{S^) = S 

• for all 5^5, S^{s) ^ 0 

• Dom{F^) = FinSeq[s) x 5 

• for all w G FinSeq{S) and s ^ S: 

- U 

- for all / G TFyj^s^ ^w,sU) • ^ total function) 

- forall/GPF^’„F^,(/):^^-5^ 

• Dom{P^) = FinSeq{S) 

• for all w G FinSeq{S): 

- Dom{P^)=P^ 

- for all p G Pw^ Pw [p) ^ 

where (si, . . . , Sn)^ = x • • • x 5^. 

Every model in a F-model class M is required to be a valid F-model. 

Given two F-models M, M' G Mod(F), a many-sorted homomorphism h : 
M M' maps the values in the carriers of M to values in the corresponding 
carriers of M' in such a way that the values of functions and their dehnedness 
is preserved, as well as the truth of predicates. 

h : M ^ M' G Homomorphism = 

Model X (Sort ^ PartialFun) x Model 

Requirements on a F-homomorphism h : M ^ M' for F = (P, FF, PF, P): 

• M and M' are valid F-models 

• Dom{h) = S 

• for all s ^ hs : s^' (a total function) 

• for all w = (5i,...,5n) G FinSeq{S)^ 5 G P, / G TF^^g C PFw,s 

and ai G 5f^,...,a^ G 5^, whenever /^(ai, . . . , a^) is dehned then 
so is (ai ),..., (a^)), and in that case /z 5 (/^(ai, . . . , a^)) = 

f^' (hs^iai),. . . ,hs„ (a„)) 

• for all w = (si, . . . , s„) G FinSeq{S), p G Pw and a\ G . ,an G sff , if 

(ai, . . . ,a„) G p^‘ then (/isi(ai), • • • ,hs„{an)) G . 

Composition of homomorphisms is as usual: if /z : M ^ M' and h' : 
M' M" are F-homomorphisms for F = (S^TF^PF^P)^ then the F- 
homomorphism h' o h : M ^ M" is given by {h' o h)g = h'^ o hg for all 
5 G P. Identity homomorphisms are P-sorted identity functions. 

Proposition 2.6. The composition h' o h : M M" is indeed a F- 
homomorphism. 

Proof. Routine. □ 

Proposition 2.7. F-models together with F-homomorphisms form a cate- 
gory, Mod(F). 
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Proof. Easy. 



□ 



A signature morphism a : U ^ U' determines the many-sorted 

reduct of each A'-model resp. A'-homomorphism to a A-model resp. E- 
homomorphism, dehned by interpreting symbols of E in the reduct in the 
same way that their images under a are interpreted. 

Let M' = be a A'-model and let a : A ^ A' be a 

signature morphism where a = (a^, and E = (/S', TF ^ PF ^ P). 

The reduct of M' with respect to a is the A-model M'|cr = {S^ , F^ , P^) 
dehned as follows: 



SM ^ ^M' ^ 






PFsyJsU)) if /ere 

if/ePF, 



pM ( \ _ pM' 

\P) — 



Kip)) 



Proposition 2,8, If a : E E' is a signature morphism and M' is a E'- 
model then M'\a- is indeed a E -model. 

Proof. Routine. □ 

Suppose that A is a subsignature of A', so there is a signature inclusion 
E ^ Eh Then we sometimes write M'\jj as an abbreviation for 
and we say that a A'-model M' extends a A-model M if M'\jj = M. These 
notations are extended to classes of models, so M'\a = {Af'jcr | M' G M'} if 
G : E ^ E' and M' is a class of A'-models, and M'\e = | M' G M'} 

if (7 is a signature inclusion. 

Let h' : Ml' M2' be a A'-homomorphism and let a : A ^ A' be a 
signature morphism where E = (/S', TF , PF , P) and a = (a^, a^). 

The reduct of h' with respect to a is the A-homomorphism h'\cr : Ml'\cr 
M2'\cr dehned by {h'\cr)s = 5 G S'. If A is a subsignature of E' 

then we sometimes write h'\E as an abbreviation for h'\E^E'- 

Proposition 2,9, If a : E ^ E' is a signature morphism and h' : Ml' 
M2' is a E' -homomorphism then h'\cr : Ml'\(j M2'\(j is indeed a E- 
homomorphism. 

Proof. Easy. □ 

Proposition 2.10. Reduct of models and homomorphisms extends Mod to 
a finitely continuous functor Mod : Sig^^ ^ CAT (i.e. Mod takes finite 
colimits in Sig to limits in CAT). 
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Proof. It is easy to see that Mod is a functor. For continuity, see [38] for a 
sketch of the proof of a more general result; cf. [15]. □ 

Let h : M ^ M' be a i7-homomorphism. If there is a i7-homomorphism 
h~^ : M' M such that h o h~^ is the identity on M' and h~^ oh is the 
identity on M then h is a U- isomorphism and we write M = Mb 



2.1.3 Sentences 



The many-sorted terms on a signature U and a set X of variables consist of 
variables from X together with applications of qualihed function symbols to 
argument terms of appropriate sorts. We refer to such terms as fully- qualified 
terms^ to avoid confusion with the terms of the language considered later in 
this chapter, which allow explicit qualihcations to be omitted when they are 
determined by the context. 

Following the order of presentation in the Casl Summary, we leave the 
syntax of variables (Var) unspecihed for now. It will be dehned in Sect. 2.4 
below. 

X G Var 

X G Variables = Sort ^ FinSet{Var) 

Xs G QualVarName = Var x Sort 

Requirements on an /S-sorted set of variables X: 

• Dom{X) = S 

• for all 5, 5 ' G /S' such that s ^ s\ Xg D Xg' = 0. 

In a qualihed variable name Xg, it is required that 5 G S'. 

We write X + for the (S' U {5})-sorted set of variables such that 






( XgU {x} if 5 G Dom{X) 
\ {x} otherwise 



and {X + = Xgf \ {x} for s' e S such that s' ^ s. We write X ^ X' 

for the extension of this to arbitrary S' -sorted sets of variables X'. 

Proposition 2.11. If X is valid for S and X' is valid for S' then X X' is 
valid for S U S' . 



Proof Easy. □ 

If x'^ ^ x^ for dl\ 1 < i ^ j < n then we use {x \^ , • • • , } to abbreviate 

{^sil + • • • + (The pre-condition means that the order is immaterial, 

as the set notation suggests.) 

The dehnitions of fully-qualihed terms and formulas are mutually recur- 
sive. 
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t G FQTerm = 

Xs G QualVarName l±) 

fws{ti^ . . . ^tn) G QualFunName x FinSeq{FQTerm) l±) 

(f ^ t \ t' ^ Formula x FQTerm x FQTerm 



For any t G FQTerm^ define sort{t) G Sort as follows: 



sort{xs) = s 

SOrt{fw^s{tl, . . . ,tn)) = 5 

sort{(p T I t") = I 



sort{T) if sort{T) 
undefined otherwise 



sort{T') 



Requirements on a fully-qualified i7-term t over an /S-sorted set of variables 
X, for X = (5, TF,PF,P): 

• if t is X 5 , then Xg is valid for S and x G X 5 

• if t is fw,s{ti , . . . , tn), then: 

“ fw,s is a valid qualihed function name over F 

- ti , . . . , are valid fully-qualihed X-terms over X 

- \w\ = n 

- w = {sort{ti), . . . , sort{tn)) 

• if t is (f ^ t' \ t", then: 

- (f is a valid X-formula over X 

- t' and t" are valid fully-qualihed X-terms over X 

- sort{T) = sort{T^) 

The fully-qualihed term (p ^ t \ t' is only needed to deal with the conditional 
term construct, see Sect. 2.5.4 below. An alternative is to deal with these by 
transformation as described in Sect. 1: 2. 5. 4 of the Casl Summary. Then fully- 
qualihed terms of the form p ^ t \ T are not required. Since these terms are 
non-standard, this is what is done in the proof calculus for basic specihcations 
in Sect. IV:2. 

The many- sorted sentenees in Sen(X) are sort-generation constraints - de- 
scribed below - and the usual closed many-sorted hrst-order logic formu- 
las, built from atomic formulas (application of qualihed predicate symbols 
to argument terms of appropriate sorts, assertions about the dehnedness 
of fully-qualihed terms, and existential and strong equations between fully- 
qualihed terms of the same sort) using quantihcation and logical connectives. 
Predicate application, existential equations, implication and universal quan- 
tihcation are taken as primitive, the other forms being regarded as derived. 



p G Formula 
Pw {tl 5 • • • 5 ^n) ^ 

t^T e 
false G 
p ^ p' e 
yxg.p G 



QualPredName x FinSeq{FQTerm) l±) 
FQTerm x FQTerm i±) 
unit l±) 

Formula x Formula l±) 

QualVarName x Formula 
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Requirements on a i7-formula (p over an /S-sorted set of variables X, for = 
(5, TF,PF,P): 

• if (/:? is (ti , . . . , tn) , then: 

- is a valid qualified predicate name over E 

- ti, . . . , are valid fully-qualified X-terms over X 

- \w\ = n 

- w = {sort(ti)^ . . . ^ sort(tn)) 

• li p IS t = t' ^ then: 

- t and t' are valid fully-qualified X-terms over X 

- sort(t) = sort(t') 

• if p is p' ^ p" ^ then p' and p" are valid X-formulas over X 

• if (/:? is \/Xs-p' then: 

- Xs is valid for S 

- p^ is a valid X-formula over X + {xg} 

Abbreviations are defined as follows: 

^p abbreviates p ^ false 
pV p' abbreviates {^p) ^ p' 
p A p' abbreviates ^{^p V ^p') 
p PA p' abbreviates {p) ^ p'^ A {^p' ^ p') 
true abbreviates ^false 
D{t) abbreviates t = t 

t = f abbreviates {D{t) t = t') A {D(t') ^ t = t') 

V{x^i , . . . , xfn}.p abbreviates . • • • \/x^n .p 
3X.p abbreviates -^(yX.^p) 

3\X.p abbreviates 3X.{p A yX.{p[X/X] ^ X = X)) 

where in the last clause the variables X are variants of X chosen to avoid all 
variable clashes, p[X/X] is substitution, and X = X abbreviates the evident 
conjunction of equations. The notation for strong equations is deliberately 
more explicit than that in Casl itself, where undecorated equality is used. 

Let X be an /S-sorted set of variables, for X = (/S', TP , PF , P). The set 
FV (t) of free variables of a fully-qualified X-term t over X, and the set FV (p) 
of free variables of a X-formula p over X, are defined simultaneously by 
induction as follows, giving an S'-sorted set of variables: 

• FV{xs) = {xs} 

• FV{fls{tu . , t^)) = FV{P) U . . . U FV{tn) 

• FV{p' t' I t") = FV{p') U FV{t') U FV{t") 

• FV{p^{P , . . .,tn)) = FV{h) U . . . U FV{tn) 

• FV(ti = t2) = FV(ti) U FV(t2) 

• Fvlfalse) = 0 

• FV{p^ p'') = FV{p') U FV{p") 

• FV{^Xs.p') = FV{p')\{xs} 
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If n = 0 then (fi A • — A (fn means true^ (fi V • • • V (fn means false ^ and 
Vx^i. • • means cp. (This is metanotation: ellipses are not included in 

the syntax of sentences.) 

Let (fhe a i7-formula over X and let (a^, a^) be a signature mor- 

phism a : X ^ X' where = (5, TF,PF,P) and = {S', TF',PP',P'). 
Let X' be the 5"-sorted set of variables such that X', = IJcrS(s)=s' for all 
5 ' G S' . The translation of <p along a is the X'-formula (7{<p) over X' obtained 
by replacing each qualihed variable name Xg in <p by , each qualihed func- 
tion name f^js such that / G TF^js by crjg (/)crS(w;s), each qualihed function 
name f^js such that / G PF^js by cr^5(/)crS(w;s), and each qualihed predicate 
name pyj by (T^{p)aS(w)- 

Proposition 2 , 12 , If a : X X' is a signature morphism and p is a X- 
formula over X then cr{(p) is indeed a X' -formula over X' . If X is empty then 
so is X' . 

Proof. Straightforward. □ 



The sentences Sen(X) also include sort- generation eonstraints, used to re- 
quire that models are reachable on a subset of sorts. 



{S',F',a) G Constraint = SortSet x FunSet x SignatureMorphism 

Requirements on a X-constraint {S',F',a): 

• a : X ^ X where X = (S, TP, PF, P), and then: 

• S' CS 

• Dom{F') = FinSeq{S) x S 

• for all ws G FinSeq{S) x S, F'^^ C U PF ws 

Let a' : X ^ X" be a signature morphism. The translation a' {S' , F' ,a) 
of a X-constraint {S',F',a) along a' is the ^''-constraint {S',F',a' o a). 

Proposition 2.13. Translating a X -eonstraint along a : X ^ X' gives a 
X' -eonstraint. 

Proof. Obvious. □ 

We use the abbreviation {S',F') for the X-constraint {S' , F' , idz;)- Only 
constraints of this kind are introduced by Casl specihcations, see Sects. 2.3.4 
and 2.3.5. Constraints with non- identity third components arise only when 
constraints introduced by Casl specihcations are translated along signature 
morphisms. 



G Sentenee = Formula l±) Constraint 
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Requirements on a i7-sentence 

• if ^0 is a formula, it is required to be a valid i7-formula over the empty set 
of variables 

• if ^0 is a constraint, it is required to be a valid i7-constraint 

Proposition 2.14. The mapping from signatures U to sets of U-sentenees, 
together with translation of sent enees along signature morphisms, gives afune- 

tor Sen : Sig ^ Set. 

Proof. The requirement that variables cannot be overloaded is crucial because 
it allows the translated sets of variables X' above to be formed without the 
use of disjoint union. Given this, the proof is straightforward. □ 



G Enriehment = Extension x EinSet{Sentenee) 
Requirements on an enrichment relative to a signature X: 

• Z\ is a signature extension relative to X 

• Each \s d. X VJ Z\-sentence 



2.1.4 Satisfaction 



The satisfaction of a i7-formula in a i7-model is determined as usual by 
the holding of its atomic formulas w.r.t. assignments of values to all the 
variables that occur in them. The value of a term may be undehned, due 
to the presence of partial functions. Note, however, that the satisfaction of 
sentences is two- valued. 

A predicate application holds iff the values of all its argument terms are de- 
hned and give a tuple that belongs to the predicate. A dehnedness assertion 
holds iff the value of the term is dehned. An existential equation holds iff the 
values of both terms are dehned and identical, whereas a strong equation 
holds also when the values of both terms are undehned. 



p G Assignment = Sort PartialFun 

Let X = (/S', TF, PF, F) be a signature, M a A-model, and X an S'-sorted set 
of variables. Requirements on an assignment p of X into M, written p : X ^ 
M: 

• Dom{p) = S 

• for all s e ps : Xg ^ 

If a G then we write p[xs ^ a] for the assignment of X X into 
M such that p[xg ^ o]s{x) = a, p[xs ^ o]s{x') = Ps{x') for x' ^ x, and 
p[xs a]s>{x') = ps'{x') for s' ^ s and x' ^ x. 
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We now simultaneously define three things inductively by means of inference 
rules: 

• the value |t]^ of a fully-qualihed i7-term t over X in a X-model M with 
respect to an assignment p : X M; 

• satisfaction of a X-formula (p over X by a X-model M under an assignment 
p : X ^ M, written M \=p and 

• non- satisfaction of (p hy M under p, written M (p. 

We dehne both ^ and ^ so as to avoid negative occurrences of ^ in its own 
dehnition. 

Psjxs) = a 
Ia^«lp= a 

[*i]p= ■■■ ltnjp=an . . . ,a„) = a 

I/tos (^1 ; • • • ) ^n)lp~ O, 

According to this rule, the value of fws{ti^ • • • , ^n) is dehned only if the values 
of ti, . . . , tn are dehned and the resulting tuple of values is in Dom{f^). 

lt]p= a M ^p(fi lt']p= a' 

\ t'lp= a l^^t \ t'lp= a' 

lti]p=ai ■■■ ltnjp=an {ai,...,an) ep^ 

[=p Pyj {tlj . . . , ^n) 

\tj\p not defined for some 1 < j < n 
M '^pPw{tl,---,tn) 

[ti]p=ai ■■■ |f„lp= a„ (ai, . . . ,a„) 

M '^pPw{tl,---,tn) 

Mp= a I^1p= « 

M'^pt = t' 

|t]p not defined W\p defined 

M'fpt = t' M^pt = t' 

Mp= Q I^1p= g 7^ g' 

M^pt = t' 



M ^p false 
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Mhp 

M (f ^ (f' M ^p (f ^ (f' 

M ^p (f M ^p (f' 

M ^p (f ^ (f' 



M ^p[x.,^a] ^ for all ae 

M |=p \/xg.(p 

CL ^ S M ^p[2^si-^a] ^ 

M ^p yxs.(f 

Proposition 2.15. M^p^iff^iM if). 

Proof. By induction on the structure of (p. □ 



A sort-generation constraint (5", F') is satisfied in a A-model M if the carri- 
ers of the sorts in S' are generated by the function symbols in F' from the val- 
ues in the carriers of sorts not in S'. Then M \= (5", F', a) iff M|cr H 

Suppose M is a A-model and {S' , F', a) is a F-constraint with a : F ^ F. 
Then M satisfies {S', F',a), written M \= {S' ,F' , a), if the carriers of M|cr of 
the sorts in S' are generated by the function symbols in F' , i.e. for every sort 
s ^ S' and every value a G 5^1^, there is a F-term t containing only function 
symbols from F' and variables of sorts not in S' , and no conditional subterms 
(terms of the form p ^ t' \ t"), such that |t]^= a for some assignment p into 
M\,. 

A F-model M satisfies a F-sentence written M \= if: 

• ^0 is a formula p and M ^0 p, where 0 is here the empty assignment from 
the empty set of variables 

• ^0 is a constraint {S', F' , a) and M \= {S' ,F' , a) 

We write M ^ for ^(M ^ fi). 

Proposition 2.16. Satisfaetion is eompatihle with reduets of models and 
translation of sentenees: if a : F ^ F' is a signature morphism, is a 
F-sentenee and M' is a F' -model, then 

iff M'^a{fi) 

Proof. See Sect. 3.1 of [41]. □ 

Theorem 2.17. Sig; Mod; Sen and \= form an institution [20]. Sig is 
finitely eoeomplete and Mod supports amalgamation of models and homo- 
morphisms. 



Proof. Directly from Props. 2.3, 2.10, 2.14 and 2.16. 



□ 
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Proposition 2 . 18 . Satisfaction is preserved and reflected by isomorphisms: if 
M, M' are E -models such that M = M' and is a E -sentence, then M \= 

Proof. Straightforward. □ 

The rest of this chapter gives the abstract syntax of the constructs of many- 
sorted basic specihcations, and dehnes their intended interpretation. Well- 
formedness of phrases of the abstract syntax is dehned by the static semantics. 
The model semantics, which yields a class of models as result, provides the 
corresponding model-theoretic part of the semantics. In this chapter, only 
basic specihcations themselves (phrases of type BASIC- SPEC) are given both 
static and model semantics; other phrase types are given only static semantics. 
In this particular case, the result of the static semantics fully determines the 
result of the model semantics, but that is not the case in other parts of Casl. 



2.2 Basic Items 



A many-sorted basic specihcation BASIC- SPEC is a sequence of BASIC- ITEMS 
constructs. It determines an enrichment containing the sorts, function sym- 
bols, predicate symbols and axioms that belong to the specihcation; these 
may make reference to symbols in the local environment. This enrichment 
in turn determines a class of models. 



BASIC-SPEC ::= basic-spec BASIC-ITEMS* 



A h BASIC-SPEC > {A, P) E,M^ BASIC-SPEC ^ M' 

(Z\, P) is an enrichment relative to E. A4 is required to be a model class over 
E. Each model in Ad Ms a valid E U Z\-model that extends a model in A4 and 
satishes P. 

As will become clear in Chap. 4, one use of basic specihcations in Casl 
is in extending existing specihcations. Such a basic specihcation will often 
make reference to the sorts, function symbols and predicate symbols of the 
existing specihcation (the local environment), for instance to declare a new 
function taking an argument of an existing sort. This context is captured by 
the signature E in the above judgements, with the A-models in Ad giving all 
the possible interpretations of these symbols. In contrast, variable declarations 
are local to basic specihcations. 

E,0\- BASIC-ITEMSi > {Ai,Pi),Xi 



A U Z\i U • • • U An-l,Xi + • • • + Xn-l k BASIC-ITEMSn > {An,^n),Xn 

E h basic-spec BASIC-ITEMS^ . . . BASIC-ITEMS^ > 
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Making the incremental information from all the preceding BASIC-ITEMS avail- 
able to the next one in sequence gives linear visibility. The use of -I- to combine 
variable sets means that a later declaration of a given variable will override 
an earlier declaration of the same variable. 

S h basic-spec BASIC-ITEMS* t> (A, <F) 

S,Mh basic-spec BASIC-ITEMS* ^ 

{(r U Zi)-model M' | M%^j:ua e M and M' for all ip e >F} 



Each BASIC-ITEMS construct determines part of a signature and/or some 
sentences (except for VAR- ITEMS, which merely declares some global vari- 
ables). There is linear visibility of declared symbols and variables in a list 
of BASIC-ITEMS constructs, except within a list of datatype declarations. 
Verbatim repetition of the declaration of a symbol is allowed, and does not 
affect the semantics. 



BASIC-ITEMS ::= SIG-ITEMS I FREE-DATATYPE I SORT-GEN 

I VAR- ITEMS I LOCAL- VAR-AXIOMS I AXIOM- ITEMS 



S,X \- BASIC-ITEMS > 

X is required to be a valid set of variables over the sorts of S. {A,'!') is an 
enrichment relative to S, and X' is a valid set of variables over the sorts of 
Xyj A. (Actually, X' will be a valid set of variables over the sorts of X since 
there happens to be no construct of BASIC- ITEMS that both declares variables 
and introduces signature components.) 

A h SIG-ITEMS t> (A, A', V/) 

V, X h SIG-ITEMS qua BASIC-ITEMS t> (A U A', V^), 0 

X h FREE-DATATYPE t> (A, 'P) 

V, X h FREE-DATATYPE qua BASIC-ITEMS > (A, 0 

X h SORT-GEN t> (A, 'P) 

X, X h SORT-GEN qua BASIC-ITEMS > (A, 0 

S h VAR- ITEMS > X' 

(5, TF, PF, P), X h VAR-ITEMS qua BASIC-ITEMS t> (0, 0), X' 

X, X h LOCAL-VAR- AXIOMS t> 

X,X h LOCAL-VAR-AXIOMS qua BASIC-ITEMS t> (0,V'),0 

X, X h AXIOM- ITEMS > 

X, X h AXIOM-ITEMS qua BASIC-ITEMS t> (0, ^), 0 
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2.3 Signature Declarations 



A list SORT-ITEMS of sort declarations determines some sorts. A list 
OP- ITEMS of operation declarations/definitions determines some operation 
symbols, and possibly some sentences; similarly for predicate declara- 
tions/definitions PRED-ITEMS. A list DATATYPE- ITEMS of datatype declara- 
tions determines some sorts together with some constructor and (optional) 
selector operations, and sentences defining the selector operations. 



SIG-ITEMS ::= SORT-ITEMS I OP-ITEMS I PRED-ITEMS I DATATYPE- ITEMS 



U h SIG-ITEMS t> (A, A', If') 

(A U A', If') is an enrichment relative to U. 

Here, A' are the selectors declared by DATATYPE-DECLs in SIG-ITEMS and 
A is everything else declared in SIG-ITEMS. These need to be kept separate 
here because they are treated differently by the sort-generation construct, see 
Sect. 2.3.5. 



U h SORT-ITEMS > (A, 

E h SORT-ITEMS qua SIG-ITEMS t> {A, 0, If') 

E h OP-ITEMS t> (A, If") 

E h OP-ITEMS qua SIG-ITEMS > {A, 0, If') 

r h PRED-ITEMS > {A, If') 

E h PRED-ITEMS qua SIG-ITEMS t> {A, 0, If") 

r h DATATYPE- ITEMS t> {A, A', If'), W 
E h DATATYPE-ITEMS qua SIG-ITEMS > (A, A', If") 



2.3.1 Sorts 

SORT-ITEMS : := sort-items S0RT-ITEM+ 
SORT-ITEM ::= SORT-DECL 



E h SORT-ITEMS > (A, If') 
[A,]]/) is an enrichment relative to E. 



E h SORT-ITEMi > (Aj, If'i) ■ ■ ■ E S0RT-ITEM„ > (A„, lf'„) 
E h sort-items SORT-ITEMi . . . S0RT-ITEM„ > 

(AiU---UA„,<f'iU---Ulf'„) 
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The only reason why we have U h SORT-ITEMS > (^,^) rather than simply 
h SORT- ITEMS > /S' (and similarly for SORT-ITEM below) is to accommodate the 
extension to subsorts in Chap. 3 where A will include a subsorting relation 
and W will include axioms for dehned subsorts. 



i: h SORT-ITEM > {A,^) 
is an enrichment relative to E. 

h SORT-DECL > S 

E h SORT-DECL qua SORT-ITEM > ((S', 0, 0, 0), 0) 



Sort Declarations 



A sort declaration SORT-DECL declares each of the sorts given. 



SORT-DECL ::= sort-decl S0RT+ 
SORT ::= SORT-ID 



h SORT-DECL > S 



h sort-decl si . . . s„ t> {si, . . . , s„} 

As promised in Sect. 2.1.1, we now define the universe Sort of sort names. 

Sort = SORT- ID 



2.3.2 Operations 

OP-ITEMS ::= op-items 0P-ITEM+ 
OP-ITEM ::= OP-DECL I OP-DEFN 



r h OP-ITEMS t> (A,!Z/) 
is an enrichment relative to S. 



S h OP-ITEMi > (Ai.lf'i) 

r U Z\i U ■ ■ ■ U Z\„-1 h 0P-ITEM„ [> {An, 'I'n) 

E h op-items OP-ITEM^ . . . 0P-ITEM„ > (Z\i U ■ ■ ■ U Z\„, U ■ ■ ■ U If'n) 

Making the signature extensions from all the preceding OP-ITEMs available 
to the next one in sequence gives linear visibility. This is required here for 
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the sake of UNIT-OP-ATTR attributes and operation definitions, both of which 
may refer to previously-declared function symbols. 



i: h OP-ITEM > 

is an enrichment relative to E. 
Rules elided (see Sect. 1.3). 



Operation Declarations 



An operation declaration OP-DECL declares each given operation name as 
a total or partial operation, with prohle as specihed, and having the given 
attributes. If an operation is declared both as total and as partial with the 
same prohle, the resulting signature only contains the total operation. 



OP-DECL 

OP-NAME 

OP-TYPE 

TOTAL-OP-TYPE 

PARTIAL-OP-TYPE 

SORT-LIST 



= op-decl 0P-NAME+ OP-TYPE OP-ATTR* 
= ID 

= TOTAL-OP-TYPE | PARTIAL-OP-TYPE 
= total-op-type SORT-LIST SORT 
= partial-op-type SORT-LIST SORT 
= sort-list SORT* 



As promised in Sect. 2.1.1, we now dehne the universe FunName of oper- 
ation names. 



FunName = ID 



(Recall from Sect. 2.1.1 that operations are also referred to as functions, hence 
FunName.) 



E h OP-DECL > {A,F) 



{A^F) is an enrichment relative to E. 



(5, TF, PF, P) = E ws = ((51, . . . , 5^), 5) 

{si, . . . , s„, s} C S' A = (0, {ws 1-^ {/S . . . , /”}}, 0, 0) 

r U h OP-ATTRi > If'ii ■ ■ ■ r U h OP-ATTRi > 

hOP-ATTRp[>!?'ip ■■■ r U /g, h OP-ATTRp > 
S h op-decl n • • • /" 

(total-op-type (sort-list Si . . . Sm) s) 

OP-ATTRi . . . OP-ATTRp > 

{A, (!Z/ii U ■ ■ • U U • ■ • U ('f'lp U • ■ ■ U ’I'np)) 
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{S,TF,PF,P) = S ws = {(si,...,sm),s) 

{si, . . . , Sm, s} C S' A = (0, 0, {ws 1 -^ , /”}}, 0) 

PUA, /i, h OP-ATTRi t>Fn ■■■ r U Zi, /S. ^ OP-ATTRi > Fni 

SUA, fl, h OP-ATTRp oFip ■■■ SuAJl^.h OP-ATTRp > Fnp 

S h op-decl Z'- . . . /" 

(partial-op-type (sort-list si . . . s^) s) 

OP-ATTRi . . . OP-ATTRp > 

{A, U • • • U U • • • U (!Z^lp U • • • U ^np)) 

The use of U to combine the extensions produced by these rules, in the rules 
for OP- ITEMS and BASIC-SPEC, ensures that when an operation is declared 
both as total and as partial with the same prohle, the resulting signature only 
contains the total operation. This is the purpose of the reconcile function in 
the dehnition of union, see Sect. 2.1.1. 

Operation Attributes 



Operation attributes assert that the operations being declared (which must 
be binary) have certain common properties: associativity^ commutativity^ 
idempotency and/or having a unit. (This can also be used to add attributes 
to operations that have previously been declared without them.) 



OP-ATTR : := BINARY-OP-ATTR | UNIT-OP-ATTR 

BINARY- OP -ATTR ::= assoc-op-attr | coimn-op-attr | idem-op-attr 

UNIT-OP-ATTR ::= unit-op-attr TERM 



UJujs ^ OP-ATTR 

fujs is required to be a qualihed function name over U. ^ is a set of U- 
sentences. 



ws = ((5, 5), 5) 

^ifws ^ assoc-op-attr > 

\y^sA/ysA/Zs-fws(As'jfws{yS'j^s)) — f ws{f WsiAs-jUs) -j 

ws = ((5, 5), s') 

P,fws I- comm-op-a.ttr[> {\/xs.\/ys.ns{xs,ys) = fwsiVs^Xs)} 
WS = ((5, 5), 5) 

U,fws ^ idem-op-attr > = Xg} 

ws = {{s,s),s) 

fws ^ unit-op-attr TERM > {p, p'} 



where F is 
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quantification universal 
(var-decl x s) 

(strong-equation 

(application (qual-op-name / (total-op-type (sort-list s s) s)) 
(terms TERM (qual-var X s))) 

(qual-var x 5)) 
and F' is 

quantification universal 
(var-decl x s) 

(strong-equation 
(qual-var x s) 

(application (qual-op-name / (total-op-type (sort-list s s) s)) 
(terms TERM (qual-var x s)))) 

if / G TFwsi for TF , PF , P) = and similarly with partial-op-type 

in place of total -op -type if / G PFyjg- 

This rule is more complicated than those for the other forms of operation 
attribute because the term supplied may be ambiguous due to the presence 
of overloaded operations that cannot be resolved. The static semantics of 
formulas in Sect. 2.5 below yields a result only when this is not the case; 
otherwise the attribute is ill-formed. 

Operation Definitions 

A total or partial operation may be defined at the same time as it is declared, 
by giving its value (when applied to a list of argument variables) as a term. 
The operation name may occur in the term, and may have any interpretation 
satisfying the equation - not necessarily the least hxed point. 



OP-DEFN ::= op-defn OP-NAME OP-HEAD TERM 

OP-HEAD ::= TOTAL-OP-HEAD | PARTIAL- OP-HEAD 

TOTAL-OP-HEAD ::= total-op-head ARG-DECL* SORT 

PARTIAL-OP-HEAD ::= partial-op-head ARG-DECL* SORT 

ARG-DECL ::= arg-deci VAR+ SORT 



A h OP-DEFN > {A,F) 
is an enrichment relative to F. 

(5, TF,PF,P) = F 5 h ARG-DECL* > (xi^,...,x^^) 

= (-^l, • • • , Sn) S ^ S 

A = (0, {(w,s) 1 -^ {/}},0,0) X = complete{{xl^, . . . ,xlj, S) 
SUA,X \- F\>t = t' 

X h op-defn / (total-op-head ARG-DECL* s) TERM t> {A, {yX.t = t'}) 
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where F is 

strong-equation 

(application 

(qual-op-name / (total-op-type (sort-list si . . . Sn) s)) 
(terms (qual-var Si) . . . (qual-var a;" Sn))) 

TERM 

(S, TF, PF,P) = E 5 h ARG-DECL* > , • • • , 

w = (si, ■ ..,s„) s e S 

A = (0, 0, {(w, s) {/}}, 0) X = complete{{xl _^, . . . , S) 
EuA,XhFt>t = t' 

E h op-defn/ (partial-op-head ARG-DECL* s) TERM t> {A, {VX.t = t'}) 
where F is 

strong-equation 

(application 

(qual-op-name / (partial-op-type (sort-list si . . . Sn) s)) 
(terms (qual-var x^ si) . . . (qual-var x^ Sn))) 

TERM 



S h ARG-DECL* > {x \^ , . . . , ) 

Each x\. is a qualihed variable name over 5 , and x'^ ^ x^ for all 1 < z 7^ j < n. 



S h ARG-DECLi > , x ^^^ ) , 5 i 

S h ARG-DECLp > {x ^^ , . . . , x^^^),Sp 
{x ^\. . {F\. . = 0 for all 1 < z 7^ j < J9 

S h ARG-DECLi . . . ARG-DECL^ > {x \\,. . . , x \^^ , . . . , . . . , 

S h ARG-DECL > (xi, . . . , Xn)^s 
5 is a sort in S and xi 7^ Xj for all 1 < z 7^ j < n. 

s ^ S Xi ^ Xj for all 1 < z 7^ j < n 

S h arg-decl xi . . . Xn s> (xi, . . . , 5 

2.3.3 Predicates 

PRED-ITEMS ::= pred-items PRED-ITEM+ 

PRED-ITEM ::= PRED-DECL | PRED-DEFN 
PRED-NAME : := ID 
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U h PRED- ITEMS > (A, 

{A,'!') is an enrichment relative to S. 

E h PRED-ITEMi t> {Ai,^i) 

r U Z\i U • • ■ U Z\„_1 I- PRED-ITEM„ t> (Z\„, ^„) 

E h pred-items PRED-ITEMi . . . PRED-ITEM„ t> 

(Z\i U ■ ■ ■ U Z\„, if-i U ■ ■ ■ U if-n) 

Making the signature extensions from all the preceding PRED-ITEMs available 
to the next one in sequence gives linear visibility. This is required here for the 
sake of predicate dehnitions which may refer to previously-declared predicate 
symbols. 



i: h PRED- ITEM > 
is an enrichment relative to U. 

U h PRED-DECL > Z\ 
i: h PRED-DECL qua PRED- ITEM > (Z\, 0) 
Rule for PRED-DEFN qua PRED- ITEM elided. 



As promised in Sect. 2.1.1, we now dehne the universe PredName of pred- 
icate names. 



PredName = ID 



Predicate Declarations 

A predicate declaration PRED-DECL declares each given predicate name, with 
prohle as specihed. 



PRED-DECL ::= pred-decl PRED-NAME+ PRED-TYPE 



A h PRED-DECL > Z\ 



Z\ is a signature extension relative to N. 

S h PRED-TYPE > w 

(5, TF, PF, F) h pred-decl pi . . . Pn PRED-TYPE > 

(0,0,0, {w 1-^ {pi, . . . ,p„}}) 
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Predicate Types 

PRED-TYPE ::= pred-type SORT-LIST 



S h PRED-TYPE > w 

All the sorts in w are in S. 



{si,...,Sn} ^ S 

S h pred-type (sort-list si . . . s„) t> (si, . . . , s„) 



Predicate Definitions 



A predicate may be defined at the same time as it is declared, by asserting its 
equivalence with a formula. The predicate name may occur in the formula, 
and may have any interpretation satisfying the equivalence. 



PRED-DEFN ::= pred-defn PRED-NAME PRED-HEAD FORMULA 
PRED-HEAD ::= pred-head ARG-DECL* 



A h PRED-DEFN > (Z\, T) 



is an enrichment relative to U. 



(5, TF,PF,P) = U ARG-DECL*> (xj^,...,x^^) 

w = (5i,...,5n) /! = (0,0,0,{u;^ {p}}) 

X = complete{{xl^, . . . S) XUZ\,X h FORMULA 

U h pred-defn p (pred-head ARG-DECL*) FORMULA > 

{A, {yx.pyj{x]^ , . . . o Lp]) 



2.3.4 Datatypes 



The order of the datatype declarations in a list DATATYPE- ITEMS is not sig- 
nihcant: there is non-linear visibility of the declared sorts. A list of datatype 
declarations must not declare a function symbol both as a constructor and 
selector with the same prohles. 



DATATYPE- ITEMS : := datatype- items DATATYPE-DECL+ 

The semantics of datatype declarations is by far the most complicated 
part of the semantics of basic specihcations. Before proceeding, here is an 
overview. Some examples of the results produced for free datatypes are given 
just before Sect. 2.3.5; these should be helpful in understanding that part of 
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the semantics, and working backwards to see why these results are produced 
should help in clarifying the semantics of non-free datatypes. 

The main judgements are h DATATYPE- ITEMS > and 

i: h FREE-DATATYPE The former, for a list of datatype declara- 

tions, is subordinate to the latter, for free datatypes. It is also subordinate 
to the judgement for SIG- ITEMS, when used to declare non-free datatypes. 
All of the information in its result is required to determine the semantics of 
free datatypes but some is not required in the case of non-free datatypes. 
The judgements that are subordinate to DATATYPE- ITEMS collect information 
about declared sorts, constructors and selectors and check that various re- 
strictions are satished. A complicating factor in these is non-linear visibility 
at the DATATYPE- ITEMS level. 

Metavariables are used consistently in the judgement for DATATYPE- ITEMS 
and all of its subordinate judgements. Here is a summary of what they stand 
for, where these results are formed, and where and for what they are required. 

1. A contains the sorts and constructors declared by the list of datatype 
declarations. It is formed by the rules for DATATYPE-DECL (sorts) and 
ALTERNATIVE (constructors). 

2. A' contains the declared selectors. It is formed by the rules for COMPONENTS. 
The selectors need to be kept separate from the other signature compo- 
nents for the sake of the disjointness condition in the DATATYPE- ITEMS 
rule, to generate sentences in the rule for FREE-DATATYPE, and, in the 
case of a non-free datatypes, to produce the result for SIG- ITEMS, where 
a separation is required for the sake of SORT-GEN where selectors receive 
special treatment. 

3. W contains sentences dehning the value of each selector on the values 
produced by the corresponding constructor. It is formed by the rules for 
COMPONENTS. 

4. IT is a hnite map taking each constructor name in A to the corresponding 
set of partial selectors from A' (or to 0 in case there are none). It is formed 
in the rules for ALTERNATIVES. IT is needed in the rule for FREE-DATATYPE 
to generate sentences that require a partial selector to return an undehned 
result when applied to a value produced by a constructor for which it has 
not been declared. 



A h DATATYPE- ITEMS > (Z\, A' 

(Z\ U Z\',!Z^) is an enrichment relative to E and IT is a hnite map taking 
qualihed function names over E VJ A from A to sets of qualihed function 
names over A U Z\ U Z\' from A ' . 
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S' I- DATATYPE-DECLi > (Z\i, Z\'i, If'i), Wi 

S' h DATATYPE-DECL„ > (A„, A'„, Wn 
disj oint- functions (Ai U ■ ■ ■ U A„, U ■ ■ ■ U Z\^) 
r' = r U Z\i U Z\'i u ■ ■ ■ u z\„ u 

S I- datatype- items DATATYPE-DECLi . . . DATATYPE-DECL„ t> 
(z\i u ■ ■ ■ u z\„, z\'i u ■ ■ ■ u z\;, If-i U ■ ■ ■ U If'n), U ■ ■ ■ U 



where disjoint-functions{{S, TF , PF , P), {S' , TF' , PF' , P')) means 

for all ws G Dom{TF U PF) n Dom{TF' U PF'), 

(TF U PF){ws) n{TF'u PF'){ws) = 0 

The ‘recursion’ in the premises of this rule is what provides non-linear 
visibility, making the order of the DATATYPE-DECLs not signihcant. In the sub- 
ordinate judgements, it is important to remember that the context will already 
include the signature extensions being produced. The disjointness premise im- 
plements the requirement that a list of datatype declarations must not declare 
a function symbol both as a constructor and selector with the same prohle. 

Note that if a sort is declared several times in a DATATYPE- ITEMS, with 
several lists of alternatives, the effect is the same as if the sort had been 
declared only once, but with the union of the alternative lists. 

Datatype Declarations 



A datatype declaration DATATYPE-DECL declares the given sort, and for each 
given alternative construct the given constructor and selector operations, 
and determines sentences asserting the expected relationship between selec- 
tors and constructors. 



DATATYPE-DECL : := datatype-decl SORT ALTERNATIVE+ 



A h DATATYPE-DECL > (Z\, A', W 

(A U A', is an enrichment relative to U and IT is a hnite map taking 
qualihed function names over U U A from A to sets of qualihed function 
names over A U Z\ U Z\' from A ' . 

See the beginning of Sect. 2.3.4 for an explanation of the meaning of Z\, 
Z\', ^ and W in this part of the semantics. 

h ALTERNATIVE! > [Ai, A[,^i),Wi 

A, 5 h ALTERNATIVE^ > {An, Wn 

U h datatype-decl 5 ALTERNATIVE! ALTERNATIVE 2 . . . ALTERNATIVE^ > 

(({ 5 }, 0, 0, 0) U Z\! U . . . U U . . . U zA;,, !Z^! U . . . U H^! U . . . U 
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Note that s will be a sort in U because of non-linear visibility. If a constructor 
is declared several times for one sort in a DATATYPE-DECL, the effect is the same 
as if only one constructor had been declared. If these multiple declarations 
involved different selectors, all of them are provided with all selectors for a 
given argument position of the constructor being semantically equal. 

Alternatives 



An ALTERNATIVE declares a constructor operation. Each component specihes 
one or more argument sorts for the prohle; the result sort is the one declared 
by the enclosing datatype declaration. 



ALTERNATIVE ::= TOTAL- CONSTRUCT | PARTIAL- CONSTRUCT 

TOTAL-CONSTRUCT ::= total-construct OP-NAME COMPONENTS* 
PARTIAL-CONSTRUCT ::= partial- construct OP-NAME C0MP0NENTS+ 



A, 5 h ALTERNATIVE > (Z\, A',^),W 

s is required to be a sort in U. (Z\ U is an enrichment relative to U 

where A contains exactly one function and this function has result sort 5, and 
IE is a hnite map taking this function to a set of qualihed function names 
over E yj A' from A' . 

See the beginning of Sect. 2.3.4 for an explanation of the meaning of Z\, 
Z\', W and W in this part of the semantics. In this judgement, s is the sort 
declared by the enclosing DATATYPE-DECL, the function in A is the constructor 
for this alternative, and A' are its selectors. 



A,/, ws,l hCOMPONENTSi > (sn, . . . , !Z^i) 

A, /, 1 + mi H h m^-i k COMPONENTS^ > (s^i, . . (A'^.^n) 

disjoint- funetions{Ai ^ . . . , Z\^) 

'^'5 = (('^ 11 5 • • • 5 5 • • • 5 ^nl-) ' ' ' ^nmri) 1 

(5, TF, PF, P) = E {S', TF', PF', F') = U • • • U A'^ 

h total-construct / COMPONENTSi . . . COMPONENTS^ > 

((0,{^5 ^ {/}},0,0),Z\' U...UZ\;,,Fi U-.-UF^), 

{fws ^ {9{s),s' \ s' ^ ^ {{s)^ s')}} 

where disjoint-funetions{{Si, TF\, FFi, Fi), . . . , TPn^ PF^Pn)) means 

for all i,j and ws such that 1 < i ^ j < n and 
ws G Dom{TF i U PF i) H Dom{TF j U PFj)^ 

{TF, U PFi){ws) n {TFj U PF j){ws) = 0 

Note that / will be a total function in E because of non-linear visibility. 
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UJ, ws,l hCOMPONENTSi > (sn, . . . , !Z^i) 



^ f -) 1 -|- TTli TTl fi — 1 COMPONENTStt, I> (Stt,! , • • • , Sfirun ) 5 (^n 5 ^n) 

disjoint- functions , Z\^) 

WS = ((^ii , . . . , Sira-^ , . . . , 5 tt,i , . . . , Snmn) "> '^) 

(5, TF, PF, F) = F [S', TF', PF' , F') = Z\; U • • • U 
F, 5 h partial-construct / COMPONENTSi . . . COMPONENTS^ > 

((0, 0, {ws ^ {/}}, 0), Z\'i U • ■ ■ U Zi;, •f'l U • • ■ U 
{/tos {5(s),s' I £ 'S', (jr G PF'((s), s')}} 

where disjoint- functions is defined as in the previous rule. Note that / will be 
a partial function in F because of non-linear visibility. 

The disjointness premise in both rules implements the requirement that 
the selectors within each ALTERNATIVE must be distinct. 

Components 



Each COMPONENTS construct specifies one or more argument sorts for the 
constructor operation declared by the enclosing ALTERNATIVE, and optionally 
some selector operations with sentences determining their result on values 
produced by that constructor. All sorts used must be declared in the local 
environment. 



COMPONENTS ::= TOTAL-SELECT | PARTIAL-SELECT | SORT 
TOTAL-SELECT ::= total-select 0P-NAME+ SORT 
PARTIAL-SELECT : := partial-select 0P-NAME+ SORT 



A, /, ws, m h COMPONENTS > w' , {A', F) 

f is required to be a function name in F with profile ws = {{si, . . . , Sn) , s) 
and 1 < m < n. w' is Si non-empty sequence of sorts in F and (A',F) is an 
enrichment relative to F. 

See the beginning of Sect. 2.3.4 for an explanation of the meaning of 
A' and F in this part of the semantics. In this judgement, / is the con- 
structor declared by the enclosing ALTERNATIVE, s is the sort declared by 
the enclosing DATATYPE -DECL, and m is the first argument position corre- 
sponding to these COMPONENTS. Then w' are the sorts of these arguments, so 

('^7715 • • • 5 ^m-\-\w'\—l) ' 



s' eS 



(F, FF, FF, F), /, ws, m h F > (F), (0, 0) 
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s' ^ S ((si, . . . , 5n), 5) = ws ^ for all 1 < z 7^ j < n 

(/S', TF, PF, F), /, ws^ m h total-select 5 ' > 

p times 



mm. 


, s') ^ 




3 ), 








rpTl 

• • ’ ^Sn 


}• {x\^ 5 • • • : 




))^ 












5 • • • 5 ^Sr> 


)) = m 




• • ’ ^Sn 


}• {x\^ 5 • • • : 




))^ 












5 • • • 5 


,)> = mm 



Note that . . . , will be in TF because of non-linear visibility. If the con- 
structor / is declared as total then the dehnedness conditions in the sentences 
produced are redundant but harmless. 



s' ^ S ((51, . . . , 5 ^), 5) = WS F 7^ F for all 1 < z 7^ j < n 
(S', FF, FF, F), /, m h partial-select /^ . . . /^ 5' > 

p times 





,s')^ 






3), 








• 5 ^Sn 








))^ 








4 


?),s' {fws 




5 • • • 5 ^Sr> 


)) = m 




rpTl 

• 5 ^Sr, 








))^ 








4 


?),s' {fws 




5 • • • 5 ^Sr> 


,» = mm 



Note that /^, . . . , /^ will be in PF because of non-linear visibility. If the con- 
structor / is declared as total then the dehnedness conditions in the sentences 
produced are redundant but harmless. 



Free Datatype Declarations 



A FREE-DATATYPE construct is only well-formed when its constructors are 
total. The same sorts, constructors, and selectors are declared as in ordi- 
nary datatype declarations. Apart from the sentences dehning the values of 
selectors, additional sentences require the constructors to be injective, the 
ranges of constructors of the same sort to be disjoint, the declared sorts to be 
generated by the constructors, and that applying a selector to a constructor 
for which it has not been declared is undehned. 



FREE-DATATYPE : := f ree-datatype DATATYPE -I TENS 



A h FREE-DATATYPE > (Z\, F) 



(Z\,F) is an enrichment relative to F. 
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U h DATATYPE- ITEMS t> (A, A', <F), W 
(S, TF, PF, P) = E {S', TF', 0, P') = A S" = S U S' 

E h free-datatype DATATYPE- ITEMS > 

(A U A' , F U {injective{fw ,s) \ w G FinSeq{S"), s G S" , f G j,} 

U {disjoint-ranges{fw^s, gyji ^s) 

\w,w'e FznSeq{S''),se S",fe TF '^^,,9 G TF'^,^, 
such that w ^ w' or f ^ g} 

U { undefined- selectionlfqn s,Qi^) sO 
\UsJL-,seDorn{W),g\!;J 
U {(F', complete{TF' , FinSeq{S") x 5"))} ) 



where: 

• injective{fyj^s) is the following {E U A LI Z\')-sentence which states that 
fw,s is injective: 






fw,s{ 



Sn ’ ^Si ’ 
1 






X] 

a A 

^Si 



n 



— fw,s{yl^ 5 



A 



iSi "> 

■ - Ax^ 



• • . Vs: 

= dsrr 



where (si, . . . , 5^) = w and . . . , . . . , are distinct variables. 

• disjoint-ranges {fqqj 9w' ,s) is the following {U U A U Z\')-sentence which 
states that and gw',s have disjoint ranges: 






V{a 



^ ^ Vs 



where (si, . . . ,5^) 



• • > }-^{fw,s(A = ffw',6'(ys[ > • • • > y”;.)) 

w, (s[, . . . , s'^) = w' and , x^, ^ are 



distinct variables. 

undefined- seleetion{ f w 1 9{s), s') is the following (i7 U Z\ U Z\')-sentence 
which states that the value of applying the selector g(^s),s' fo values pro- 
duced by the constructor (for which it has not been declared) is un- 
dehned: 



> • • • > a;”„ {fwAA > • • • > a;”„ ))) 



where (si, . . . , Sn) = w and . . . , are distinct variables. 



See the beginning of Sect. 2.3.4 for an explanation of A^ Af ^ and W as pro- 
duced by the judgement for DATATYPE- ITEMS. The third premise imposes the 
condition that all declared constructors are total. Note that {Sf eomplete{TFf 
FinSeq{S") x 6"')) in the last line of the rule is a sort generation constraint, and 
recall that this abbreviates {Sf eomplete{TFf FinSeq{S") x S")AdE\jA\jA')> 
This requires that all values of sorts declared by DATATYPE- ITEMS are gener- 
ated by the declared constructors. 

The following proposition states that the resulting model class is the same 
as for a free extension with the datatype declarations. 



Proposition 2,1^, Consider a deelaration free-datatype DATATYPE- ITEMS, 

a signature F and a model elass A4 over F, and suppose 
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i: h DATATYPE- ITEMS > (Z\, A' 

U h free-datatype DATATYPE- ITEMS > [A U A' 

such that DATATYPE- ITEMS fulfills the following conditions (all referring to 
fully qualified symbols): 

• The sorts in A ( and hence the constructors in A and the selectors in A! ) 
are not in the local environment U; and 

• Any selector in A' is total only when the same selector is present in all 
ALTERNATIVES for that sort 

Let C be the full subcategory of Mod(i7 U Z\ U A') containing those {U U 
A U A') -models M" such that M" ^ for all and let A4' and A4" be 

the {U U AU A') -model classes 

M' = A Ayj A')-model M' 

I LL'\z!^ijuauA' ^ A4 and M' ^ C is free over M'\z!^ijuauA' 
w.r.t. (e^euauA' : C Mod(i7)} 

M" = {{UUAU A')-model M' 

I M'\jj^jjuaua> e M and M' ^ for all G T'} 



Then M' = M" . 



Proof. See Theorem 3.11 in Sect. 3.2.2 for a more general result. □ 

A few examples should help to clarify the above dehnitions. Since there is 
no overloading in these examples, ordinary function names are used instead of 
qualihed function names to reduce clutter, and the usual syntax for variable 
typing is used. 

Here is an example of a free datatype declaration where all alternatives 
are constants, which corresponds to an unordered enumeration type: 

free type Color ::= red \ blue 

The result is the following enrichment (relative to the empty signature): 

(A,{red() = red{) ^ true^ 
blue{) = blue{) ^ true^ 

~^{red{) = blue{)), 

~^{blue{) = red{))^ 

{{Color}, TFfidjj)} 

where E = {S, TF, PF, P) is the signature containing the sort Color, the total 
function symbols red and blue, and no partial function symbols or predicate 
symbols. The hrst two sentences are from the injective condition and are 
t autologous, as always for nullary constructors. The next two sentences are 
from the disjoint-ranges condition and are equivalent (such duplication will 
always be present but it does no harm). The hnal sentence is a sort generation 
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constraint which requires every value of sort Color to be produced by either 
red{) or blue{). Each model has a carrier of sort Color containing exactly two 
values. 

Here is the standard example of lists, with selectors: 

free type List ::= nil \ cons {first CElem; rest CList) 

The result is the following enrichment (relative to a signature E containing 
just the sort Elem): 

{A, {\/x:Elem, E :List.D{cons{x^x')) ^ first {cons {x^x')) = x, 
Mx'.Elem^x' '.List. D {cons {x^x')) ^ rest {cons {x^x')) = x\ 
nil{) = nil{) ^ true^ 

\/x:Elem, x':List^ yiElem, y''.List. 

cons{x, x') = cons{y^ y') ^ x = y f\x' = y' ^ 

\/x'.Elem^x' '.List.^{nil() = cons{x^x'))^ 

Mx'.Elem^x' '.List.^{cons{x^x') = nil{))^ 

-^D {first {nil {))), 

-^D {rest {nil {))), 

{{List}, TEfidjjuA)} 

where A = {S, TE , PE , P) is the signature extension (relative to E) con- 
taining the sort List, the total function symbols nil and cons, the partial 
function symbols first and rest, and no predicate symbols. The hrst two sen- 
tences are generated by the rules for COMPONENTS and specify the relationship 
between the constructor cons and the selectors first and rest. The next two 
sentences are from the injective condition. The next two sentences are from 
the disjoint-ranges condition; again, they are equivalent. The next two sen- 
tences are from the undefined- selection condition. The hnal sentence is a sort 
generation constraint which requires each value of sort List to be produced 
by a term of the form 



cons{xi, . . . , cons{xn, nil) . . .). 

for some assignment of values of sort Elem to the variables x\, ... ,Xn> Mod- 
els are as one would expect from this specihcation, with ‘no junk’ and ‘no 
confusion’, and the selectors dehned only for values produced by cons. 

Here is a type containing two copies of the natural numbers, with the same 
selector for both: 

free type Twonats ::= left{get : Nat) \ right{get : Nat) 

The result is the following enrichment (relative to a signature E containing 
just the sort Nat)'. 
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{A^ {Wx: Nat. D {left (x)) ^ get{left{x)) = x, 

\/ x: Nat. D {right (x)) ^ get{right{x)) = x, 

Mx'.Nat^x' : Nat. left {x) = left(x') x = x\ 

\/x:Nat, x': Nat. right (x) = right(x') x = x' , 
Wx:Nat^x':Nat.^{left{x) = right{x'))^ 

\/x:Nat^x' :Nat.^{right{x) = left{x')), 

{Twonats, TF\id^uA)} 

where Z\ is the signature extension (relative to N) containing the sort Twonats^ 
the total function symbols left^ right and get^ and no partial function symbols 
or predicate symbols, and TF' contains the total function symbols left and 
right. The hrst two sentences are generated by the rules for COMPONENTS and 
specify the relationship between the constructors left and right and the selec- 
tor get. The next two sentences are from the injeetive condition. The next two 
sentences are from the disjoint-ranges condition; once more, they are equiv- 
alent. The hnal sentence is a sort generation constraint which requires each 
value of sort Twonats to be produced by either left{x) or right {x) for some 
assignment of a value of sort Nat to x. Models are as one would expect, with 
two copies of Nat - one produced using left^ the other produced using right. 
Note that the total selector get : Twonats Nat which is present in both 
ALTERNATIVES becomes a single selector in the rule for DATATYPE -DECL: we 
have 

N, Twonats h total-construct left (total-select qet Nat) \> 



i 7 , Twonats h total-construct right (total-select get Nat) > 

{A2,A'^,T2),W2 

where A\ contains left^ A2 contains rights A[ = A'2 contains get, contains 
Wx:Nat.D{left{x)) get{left{x)) = x, F2 contains W x: Nat. D {right (x)) 
get {right {x)) = x, and TTi and TT 2 map left and right respectively to 0. 
Changing the declaration to 

free type Twonats ::= left {get : Nat) \ right {Nat) 

would cause the sentence W x: Nat. D {right (x)) ^ get{right{x)) = x to be omit- 
ted from the result, but otherwise there would be no difference. Note that the 
term get {right {x)) is still required to have some dehned value for every x, since 
get and right are total function symbols, but that value is unconstrained. This 
is an example where the equivalence stated by Prop. 2.19 does not hold, and 
indeed the total selector get violates one of its conditions. 

Finally, here is what happens when an attempt is made to dehne an empty 
type as a free datatype: 

free type Empty ::= f {Empty) 
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The result is the following enrichment (relative to the empty signature): 

(V, {yxiEmpty, y:Empty.f{x) = f{y) ^ x = y, 

{Empty ^ TE^idjj)} 

where E = (/S', TE ^ PE ^ P) is the signature containing the sort Empty ^ the 
total function symbol /, and no partial function symbols or predicate symbols. 
The hrst sentence is from the injective condition. The second sentence is a sort 
generation constraint which requires every value of sort Empty to be produced 
by a V-term containing no variables. There are no such terms since there are 
no constants of sort Empty hence this requires the carrier of sort Empty to 
be empty. But models are required to have non-empty carriers, and therefore 
there are no models. 

2.3.5 Sort Generation 

A sort generation SORT- GEN determines the same signature elements and 
sentences as its list of SIG-ITEMSs, together with a sort generation constraint 
requiring the declared sorts to be generated by the declared operations, but 
excluding operations declared as selectors. 



SORT-GEN ::= sort-gen SIG-ITEMS+ 



A h SORT-GEN > {A,E) 
is an enrichment relative to E. 

E h SIG-ITEMSi > {Ai,A[,Ei) 

A U Z\i U U • • • U An-i U A'^_^ h SIG-ITEMSn > {A^, A'^^E^) 

(5, TF, PF, P) = Z\ = Z\i U • • • U U • • • U 

(5", FF', FF', P^) = EUAUA^ F ^ 0 

A h sort-gen SIG-ITEMSi . . . SIG-ITEMS+ > 

(Z\ U U • • • U F+ U {(F, complete{TE U FF, EinSeq{S') x F'))} ) 

In this rule, A represents the signature extension declared by SIG-ITEMSi . . . 
SIG-ITEMS+, excluding the operations declared as selectors since these do not 
contribute to the resulting sort generation constraint. The predicate symbols 
in A also make no contribution. 



2.4 Variables 



Variables for use in terms may be declared globally, locally, or with explicit 
quantihcation. Globally or locally declared variables are implicitly univer- 
sally quantihed in subsequent axioms of the enclosing basic specihcation. 
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2.4.1 Global Variable Declarations 
VAR-ITEMS ::= var-items VAR-DECL+ 



S h VAR-ITEMS> X 
X is a valid set of variables over S. 

S h VAR-DECLi > Xi • • • Sh VAR-DECL^ > Xn 
S h var-items VAR-DECLi . . . VAR-DECL^ > Xi H h 



A variable declaration VAR-DECL declares the given variables to be of the 
given sort for use in subsequent axioms. This adds a universal quantihcation 
on those variables to the subsequent axioms of the enclosing basic specihca- 
tion. 



VAR-DECL ::= var-decl VAR+ SORT 
VAR ::= SIMPLE-ID 



S h VAR-DECL > X 
X is a valid set of variables over S. 



seS 

S h var-decl xi . . . Xn s > complete{{s ^ {xi, . . . , Xn}}, S) 

A later declaration for a variable overrides an earlier declaration for the same 
identiher because of the use of + to combine variable sets in the rules for 
BASIC-SPEC and VAR-ITEMS. Universal quantihcation over all declared vari- 
ables, both global and local, is added in the rule for AXIOM, see Sect. 2.5 
below. 

Var = SIMPLE-ID 



2.4.2 Local Variable Declarations 



A LOCAL-VAR-AXIOMS construct declares variables for local use in the given 
axioms, and adds a universal quantihcation on those variables to all those 
axioms. 



LOCAL-VAR-AXIOMS : := local-var-axioms VAR-DECL+ AXI0M+ 



X, X h LOCAL-VAR-AXIOMS > ^ 



X is required to be a valid set of variables over the sorts of X. is a set of 
X-sentences. 
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(5, TF,PF,P) = i: 

S h VAR-DECLi > Xi • • • 5 h VAR-DECL^ > Xm 

X ^ X X\ “h ' ' ' “h XjYi \~ AXIOMi C> 

X X + X\ + • • • + XjYi h AXIOMtt, I> 

X^X \- local-var-axioms VAR-DECLi . . . VAR-DECL^ 

AXIOMi . . . AXIOM^ > {t/ji , . . . , t/jn} 



2.5 Axioms 



Each well-formed axiom determines a sentence of the underlying basic spec- 
ihcation (closed by universal quantihcation over all declared variables). 



AXIOM-ITEMS ::= axiom-items AXI0M+ 
AXIOM ::= FORMULA 



i:, X h AXIOM- ITEMS > F 

X is required to be a valid set of variables over the sorts of X. is a set of 
X-sentences. 

X,X h AXIOMi > V'l ••• X,X h AXIOM^ > V'n 
X, X h axiom-items AXIOMi . . . AXIOM^ > {'^i, . . . , ifjn} 



X,X h AXIOMS V' 

X is required to be a valid set of variables over the sorts of X. ^0 is a X- 
sentence. 



X, X h FORMULA > (p 
X, X h FORMULA qua AXIOM > yX.if 

All declared variables are universally quant ihed. Quantihcation over variables 
that do not occur free in the axiom has no effect since carriers are assumed 
to be non-empty. 

A formula is constructed from atomic formulas using quantihcation and the 
usual logical connectives. 



FORMULA ::= QUANTIFICATION | CONJUNCTION | DISJUNCTION 
I IMPLICATION I EQUIVALENCE | NEGATION | ATOM 



X, X h FORMULA > 



X is required to be a valid set of variables over the sorts of X. (p is a X-formula 
over X. 
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Rules elided, except the one for ATOM qua FORMULA which is near the beginning 
of Sect. 2.5.3 below to keep it together with subordinate rules for atomic 
formulas. 



2.5.1 Quantifications 



Universal, existential and unique-existential quantihcation are as usual. An 
inner declaration for a variable with the same identiher as in an outer decla- 
ration overrides the outer declaration, regardless of whether the sorts of the 
variables are the same. 



QUANTIFICATION : := quantification QUANTIFIER VAR-DECL+ FORMULA 
QUANTIFIER ::= universal | existential | unique -existential 



A, X h QUANTIFICATION > (p 

X is required to be a valid set of variables over the sorts of X. (f is a X-formula 
over X. 



(5, TF,PF,P) = X 

S h VAR-DECLi > Xi • • • 5 h VAR-DECLn > Xn 

X, X + Xi H h x^ h FORMULA > if 

X,X h quantification universal 

VAR-DECLi . . . VAR-DECL^ FORMULA > VXi H V Xn^f) 



(5, TF,PF,P) = X 

S h VAR-DECLi > Xi • • • 5 h VAR-DECL^ > X^ 

X, X + Xi H h x^ h FORMULA > if 

X,X h quantification existential 

VAR-DECLi . . . VAR-DECL^ FORMULA > 3Xi H V Xn^f) 

(5, TF,PF,P) = X 

S h VAR-DECLi > Xi • • • 5 h VAR-DECL^ > X^ 

X, X + Xi H h x^ h FORMULA > if 

X,X h quantification unique-existential 

VAR-DECLi . . . VAR-DECL^ FORMULA > 3!Xi H V Xn.f) 



2.5.2 Logical Connectives 



The logical connectives are as usual, except that conjunction and disjunction 
apply to lists of two or more formulas. 
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Conjunction 

CONJUNCTION ::= conjunction F0RHULA+ 



r, X h CONJUNCTION > Lp 

X is required to be a valid set of variables over the sorts of d7. y> is a i7-formula 
over X. 



X,X'r FORMULAi > (pi 
S,X \- FORMULA 2 > (fi2 

d7, X h F0RMULA„ > (p„ 

X,X\- conjunction FORMULAi FORMULA 2 . . . F0RMULA„ t> 

(• • ■ (^1 A^2) A • ■ •) A 



Disjunction 

DISJUNCTION ::= disjunction F0RHULA+ 



X, X h DISJUNCTION > Lp 

X is required to be a valid set of variables over the sorts of X. y> is a X-formula 
over X. 



X, X h FORMULAi > (pi 
X, X h FORMULA 2 > (P2 

X, X h F0RMULA„ > y>„ 

X,X h disjunction FORMULAi FORMULA 2 . . . F0RMULA„ t> 

{■■■{lPi\J LP2)\J Lpn 



Implication 

IMPLICATION ::= implication FORMULA FORMULA 



X, X h IMPLICATION > Lp 

X is required to be a valid set of variables over the sorts of X. y> is a X-formula 
over X. 



X, X h FORMULA \> Lp X, X h FORMULA' t> Lp' 
X,X h implication FORMULA FORMULA' > Lp ^ ip' 
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Equivalence 

EQUIVALENCE : : = equivalence FORMULA FORMULA 



i:, X h EQUIVALENCE > (p 

X is required to be a valid set of variables over the sorts of X. is a X-formula 
over X. 



X, X h FORMULA Xp X, X h FORMULA' > p)' 
X,X h equivalence FORMULA FORMULA' > p PP 



Negation 

NEGATION ::= negation FORMULA 



X,X h NEGATION 

X is required to be a valid set of variables over the sorts of X. 9 :? is a X-formula 
over X. 



X, X h FORMULA > p 
X, X h negation FORMULA > x 

2.5.3 Atomic Formulas 



An atomic formula is well-formed if it is well-sorted and expands to a unique 
atomic formula for constructing sentences. The notions of when an atomic 
formula is well-sorted, of when a term is well-sorted for a partieular sorf 
and of the expansions of atomic formulas and terms, are captured by the 
rules below. 



ATOM ::= TRUTH | PREDICATION | DEFINEDNESS 
I EXISTL-EQUATION | STRONG-EQUATION 

(The following rule really belongs just before Sect. 2.5.1 above. It is here 
in order to keep it together with the subordinate rules for atomic formulas, 
because of the complications introduced by the ‘unique expansion’ require- 
ment.) 



there is a unique p such that X, X h ATOM > p 
X,X h ATOM > p 



X, X h ATOM qua FORMULA > p 
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The first premise of this rule imposes the requirement that ATOM expands to 
a unique (fully-qualihed) atomic formula. In this premise, the static seman- 
tics of ATOM occurs in a negative position (introduced by ‘‘there is a unique 
This is potentially problematic, especially since there is a circularity: the 
judgement \~ ATOM > (p depends on the judgement X^X \~ FORMULA > p' 
if ATOM contains a conditional term. But since FORMULA will then be strictly 
contained within ATOM, there is no problem: we can (implicitly) impose a 
stratihcation on the judgements for FORMULA and ATOM where the semantics 
of larger formulas/atoms is based on the (hxed) semantics of strictly smaller 
formulas/atoms. 



i:, X h ATOM > p 

X is required to be a valid set of variables over the sorts of X. pisd. X-formula 
over X. 

Rules elided, except for the following one: 

h TRUTH > p 

X, X h TRUTH qua ATOM > p 



Truth 



The atomic formulas for truth and falsity are always well-sorted, and expand 
to primitive sentences. 



TRUTH : := true-atom | false-atom 



h TRUTH > p 

p is a X-formula over X for any X and X. 



h true-atom > true 



h false-atom > false 



Predicate Application 



The application of a predicate symbol is well-sorted when there is a declara- 
tion of the predicate name such that all the argument terms are well-sorted 
for the respective argument sorts. It then expands to an application of the 
qualihed predicate name to the fully-qualihed expansions of the argument 
terms for those sorts. 
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PREDICATION ::= predication PRED-SYMB TERMS 

PRED-SYMB ::=PRED-NAME | QUAL-PRED-NAME 

QUAL-PRED-NAME ::= qual-pred-name PRED-NAME PRED-TYPE 



i:, X h PREDICATION > (p 

X is required to be a valid set of variables over the sorts of X. (p is a X-formula 
over X. 



X h PRED-SYMB > J9, (si, . . . ,5^) X, X h TERMS > (ti, . . . ,t^) 
SOrt{ti) = Si ••• SOrt{tn) = Sn 

X, X h predication PRED-SYMB TERMS > (ti, . . . , 



X h PRED-SYMB 
p is a predicate symbol in X with prohle w. 

C g P & P{si,...,Sn) 

{S, TF,PF,P) \-pl>p, (si,...,s„) 

S h PRED-TYPE t> w pe Pyj 
(/S', TF, PF, F) h qual-pred-name p PRED-TYPE > p^w 

Definedness 

A dehnedness formula is well-sorted when the term is well-sorted for some 
sort. It then expands to a dehnedness assertion on the fully-qualihed expan- 
sion of the term. 



DEFINEDNESS ::= definedness TERM 



X, X h DEFINEDNESS > p> 

X is required to be a valid set of variables over the sorts of X. (p is a X-formula 
over X. 

X, X h TERM > t 

X,X h definedness TERM > D{t) 



Equations 



An equation is well-sorted if both terms are well-sorted for some sort. It then 
expands to the corresponding equation on the fully-qualihed expansions of 
the terms for that sort. 
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EXISTL-EQUATION ::= existl- equation TERM TERM 
STRONG-EQUATION : := strong-equation TERM TERM 



i:, X h EXISTL-EQUATION > (p 

X is required to be a valid set of variables over the sorts of X. (p is a X-formula 
over X. 



X, X h TERM >t X, X h TERM' > t' sort{t) = sort{t') 
U,Xh existl-equation TERM TERM' !> t = t' 



X,X h STRONG-EQUATION > Lp 

X is required to be a valid set of variables over the sorts of X. p> is d. X-formula 
over X. 



X, X h TERM >t X, X h TERM' > t' sort{t) = sort{t') 

X, X h strong- equation TERM TERM' > t = t' 



2.5.4 Terms 



A term is constructed from variables by applications of operations. All names 
used in terms may be qualihed by the intended types, and the intended sort 
of the term may be specihed. 



TERM ::= SIMPLE-ID | QUAL-VAR | APPLICATION 
I SORTED-TERM | CONDITIONAL 



X, X h TERM > t 

X is required to be a valid set of variables over the sorts of X. t is a fully- 
qualihed X-term over X. 

Rules elided, except for the two rules in the next subsection which are for the 
case SIMPLE-ID. 



Identifiers 



An unqualihed simple identiher in a term may be a variable or a constant, 
depending on the local environment and the variable declarations. Either is 
well-sorted for the sort specihed in its declaration; a variable expands to the 
(sorted) variable itself, whereas a constant expands to an application of the 
qualihed symbol to the empty list of arguments. 
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s ^ S X G Xg 
( 5 , TF,PF,P),Xhx>Xs 

s e S / G TF U PF(^ys 
(5,TF,PF,P),Xh/>/o,,() 



Qualified Variables 



A qualified variable is well- sorted for the given sort. 



QUAL-VAR ::= qual-var VAR SORT 



h QUAL-VAR 

X is required to be a valid set of variables over the sorts of A. t is a fully- 
qualihed P-term over X. 

5 G P X G Xg 

(P, TF ^ PF ^ P), X h qual-var x s> Xg 
Operation Application 



An application is well-sorted for some sort s when there is a declaration of 
the operation name such that all the argument terms are well-sorted for the 
respective argument sorts, and the result sort is s. It then expands to an 
application of the qualihed operation name to the fully-qualihed expansions 
of the argument terms for those sorts. 



APPLICATION 

OP-SYMB 

QUAL-OP-NAME 

TERMS 



application OP-SYMB TERMS 
OP-NAME I QUAL-OP-NAME 
qual-op-name OP-NAME OP-TYPE 
terms TERM* 



X, X h APPLICATION > t 

X is required to be a valid set of variables over the sorts of X. t is a fully- 
qualihed X-term over X. 

X h OP-SYMB > /, ((51, . . . ,5n),5) X,X h TERMS > (ti, . . . ,t^) 

SOrt(ti) = 5i • • • SOrt(tn) = Sn 

X, X h application OP-SYMB TERMS > ..., 
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i: h OP-SYMB > /, ws 

/ is a function symbol in U with profile ws. 

{Sl, . . . , 5} C 5 / G TF {si,...,Sn),S U ^^(si,...,S^),S 

{51, . . . , 5} C P / G PP (si,...,s^),s 

(P, TF,PF,P) h 

qual-op-name / (total-op-type (sort-list 5 i . . . 5 ^^) 5) > 

/, ((51, . . . , 5 n), 5 ) 

. . . , 5} P P / G PP(s]^ 

(P, PP,PP,P) h 

qual-op-name / (partial-op-type (sort-list 5 i . . . 5 ^) 5) > 

/, ((51, . . . , 5 n), 5 ) 

h TERMS > 

X is required to be a valid set of variables over the sorts of F. ti, . . . , are 
fully-qualihed X-terms over X. 



X, X h TERMi > ti • • • X, X h TERM^ > tn 
X, X h terms TERMi . . . TERM^ > (ti , . . . , t^) 



Sorted Terms 

A sorted term is well-sorted if the given term is well-sorted for the given 
sort. It then expands to those fully-qualihed expansions of the component 
term that have the specihed sort. 



SORTED-TERM : := sorted-term TERM SORT 



X,X h SORTED-TERM > t 

X is required to be a valid set of variables over the sorts of X. t is a fully- 
qualihed X-term over X. 

X, X h TERM > t sort{t) = 5 

X, X h sorted-term TERM s> t 
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Conditional Terms 



A conditional term is well-sorted for some sort when both given terms are 
well-sorted for that sort and the given formula is well- formed. It then ex- 
pands to a fully-qualihed term built from that formula and the fully-qualihed 
expansions of the given terms for that sort. 



CONDITIONAL ::= conditional TERM FORMULA TERM 



h CONDITIONALS t 

X is required to be a valid set of variables over the sorts of A. t is a fully- 
qualihed A-term over X. 



A, X h TERM >t X, X h FORMULA > if X, X h TERM' S t' 
sort{t) = sort{t') 

X,X h conditional TERM FORMULA TERM' 

Conditional terms are interpreted as fully-qualihed terms, as explained in 
Sect. 2.1.3, rather than being handled by transformation of the enclosing 
atomic formula as is suggested in the Casl Summary; such a transformation 
would be difficult to dehne using this style of semantics. 



2.6 Identifiers 



The internal structure of identihers ID is insignihcant in the context of basic 
specihcations. (ID is extended with compound identihers, whose structure is 
signihcant, in connection with generic specihcations in Sect. 4.6.) 



SIMPLE- ID 
SORT- ID 
TOKEN 
ID 

MIX-TOKEN 
BRACED- ID 
BRACKET- ID 
EMPTY-BRS 



WORDS 

WORDS 

WORDS I DOT-WORDS I SIGNS I DIGIT | QUOTED-CHAR 
id MIX-T0KEN+ 

TOKEN I PLACE | BRACED- ID | BRACKET- ID | EMPTY-BRS 
braced-id ID 
bracket- id ID 

empty-braces | empty-brackets 




3 



Subsorting Specification Semantics 



The semantics of subsorted specifications is explained largely via reduction to 
the many-sorted case, already covered in Chap. 2. Section 3.1 defines the un- 
derlying concepts for subsorted specifications and explains their relationship 
to the corresponding concepts of many-sorted specifications. The remaining 
sections cover the language constructs for subsorted basic specifications, pre- 
sented as extensions to the constructs for many-sorted specifications. 



3.1 Subsorting Concepts 

This section extends the institution presented in Sect. 2.1, in order to cope 
with subsorting. 

We represent subsort inclusion by embedding (which is not required to be 
identity), commuting, as usual in order-sorted approaches, with overloaded 
operation symbols. 



3.1.1 Signatures 



A subsorted signature U consists of a many-sorted signature together with 
a pre-order of subsort embedding on its set of sorts. 



< G SortRelation = FinSet{Sort x Sort) 

(5, TF,PF,P,<) 

or A G SubSig = 

Sorts et X FunSet x FunSet x PredSet x SortRelation 

Requirements on a subsorted signature (/S', TF, PF, F, <): 

• (S', FF, PF ^ P) is a valid many-sorted signature 

• < G FinSet{S x S') 

• s < s for all 5 G S' 

• s < s' and s' < s" implies s < s" for all 5, s', s" G S' 
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< is extended pointwise to sequences of sorts, that is, w < w' \S. w = 
(si, . . . , 5^), w' = ( 5 '^, . . . , 5^) and Sj < 5 ' for all 1 < j <n. 

A subsorted signature fragment {S, TF , PF , P, <) consists of a (many- 
sorted) signature fragment (/S', TP , PF , P) and a relation < G SortRelation. 

(S', TP ^ PF ^ <) G SubsortedSig Fragment = 

SortSet X FunSet x FunSet x PredSet x SortRelation 

The union of subsorted signature fragments requires the resulting subsorting 
relation to be computed as reflexive and transitive closure, and is dehned as 
follows: 

(S', TF,PF,P,<) U (S", PP',PP',P',<') = (P, I^,PP,P, RTClos{< U <')) 

where (S,1P,TF,P) = {S,TF,PF,P) U {S' , TP' , PF' , P') and RTClos : 
SortRelation SortRelation associates each relation with its reflexive and 
transitive closure, that is, for each ~ G SortRelation such that S' = {5 | 
3s' .s ^ s' W s' ^ 5}, the result RTClos{^) is the relation inductively 
dehned by the following rules: 

s ^ s' 
s ^ s' 

seS 

* 

s ^ s 



For each subsorted signature A = (S', PP, PP ^ the relation < is rehexive 

and transitive, so that < and RTClos {<) coincide. 

Analogously to the many-sorted case, a subsorted signature extension A 
relative to a subsorted signature A is a subsorted signature fragment such 
that A U Z\ is a subsorted signature. 

(S', TF,PF,P,<) 

or Z\ G Sub sort edPxtension = SubsortedSigPragment 
It is trivial to extend Prop. 2.1 to the subsorted case. 

Proposition 3.1. If A and A' are subsorted signature extensions relative to 
P then Ac A' is a subsorted signature extension relative to P. 

Proof. Straightforward. □ 

As in the many-sorted case, a subsorted signature A is a subsignature of 
a subsorted signature P' if there is some subsorted extension A relative to P 
such that P' = P C A. 

For a subsorted signature (S', TP, PF,P,<)^ we dehne overloading rela- 
tions for operation and predicate symbols. Let / G (PP^^^^s^ U PF^^^^si) F 
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(TF^2,s2 UPF^2,s2)- Two qualified operation symbols fwi,si and fw2,s2 are in 
the overloading relation (written fwi,si fw2,s2) iff there exists a re G P* 
and s ^ S such that w < wi,W2 and 5 i, 52 < s. Similarly, two qualified predi- 
cate symbols and are in the overloading relation (written p^^ ~ p p^2 ) 
iff there exists a re G P* such that w < wi,W2. We say that two profiles of a 
symbol are in the overloading relation if the corresponding qualified symbols 
are in the overloading relation. 

Let i: = (P, TP,PP,P,<) and = {S', TF' , PF' , P' ,<’) be subsorted 
signatures. Then a subsorted signature morphism a = {a^ , , a^) 

from F to F' is a many sorted signature morphism from {S, TP , PF , P) to 
{S', TP' , PP' , P') preserving the subsort relation and the overloading rela- 
tions, that is: 

• s < s' implies <7^(5) <' a^{s')‘, 

• fws fyjs' that one of the following holds: 

- <^wFf)aHws) ~F (^wtif)a^(ws'), where Ps e TF and p,, G TF , 

- (/)aS(«,s) ~F where /„, G TF and G PF , 

- if)a'^(ws) where /„, G PF and G TF , or 

- if)a'^(ws) <^ws'(f)aHws')’ where Ps G PF and G PF; and 

• Pw p'w’ implies cr^{p)aS(w) ~'p 

Notice that the preservation of overloading relations is equivalent to the re- 
quirement that any two qualified function (predicate) symbols that are in the 
overloading relation are translated into the same (unqualified) symbol. 

ff is a subsignature of F' , we write F ^ F' for the evident subsorted 
signature morphism, called a subsorted signature inelusion. 

Proposition 3.2. The eomposition of subsorted signature morphisms does in- 
deed yield a subsorted signature morphism. 

Proof. Straightforward. □ 

Proposition 3.3. Subsorted signatures and subsorted signature morphisms 
form a finitely eoeomplete eategory, SubSig. 

Proof, ft is easy to see that SubSig is a category. Regarding finite cocom- 
pleteness, see [ 38 ]. □ 

For a subsorted signature F = {S, TF, PF, P, <), we define li^l C SigSym 
to be \{S, TF, PF,P)\, and for a subsorted signature morphism a : F ^ F' , 
we define \a\ : \F\ \F'\ as in the many-sorted case. 

Proposition 3.4. |.| : SubSig ^ Set is a faithful funetor. 

Proof. Straightforward. □ 

Proposition 3.5. A subsorted signature morphism a : F ^ F' is a signature 
inelusion iff \cf\ is an inelusion of \F\ into \F'\. 
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Proof. Straightforward. 



□ 



Any subsorted signature U is associated with a many-sorted signature 
where the embeddings of subsorts into their supersorts are explicitly added 
as operations. 

In order to dehne a reduction of subsorted signatures to many-sorted sig- 
natures, we hrst redehne the universes FunName of operation names and 
PredName of predicate names from Sect. 2.3, adding embedding, projection 
and membership symbols that differ from all those already present: 

FunName = ID l±) {em} l±) {pr} 

PredName = ID l±) {m(5) | 5 G Sort} 



Here, ‘em’, ‘pr’ and ‘m(5)’ refer to arbitrary objects, the only requirement 
being that in{s) ^ in{s') whenever s ^ s' . 

Then the many-sorted signature consists of , TF^ , PF^ , P^)^ 
where 

= 5 

^ ^ r TF^^s' U {em} if w = (s) and 5 < 5 ' 

w,s' i TFw,s' otherwise 

pr# _ I U {pr} ifw = {s') and 5 < 5 ' 

w,s y PFw,s otherwise 

_ ( Pw^ {m(5) \ s < s'} if w = (s') 

^ \Pw otherwise 



Any subsorted signature morphism a = (a^, from E to E' ex- 
tends to a many-sorted signature morphism ) 

from E^ to E'^ as follows: 



= { 

^*Zu) = { 

= { 



s 

em if w = {s)^s < s' and / = em 
if) otherwise 

pr if w = (5'), s < s' and f = pr 
^w^sif) otherwise 

in{a^{s)) if w = (s'), s < s' and p = in{s) 
(p) otherwise 



Proposition 3.6. The eonstruetion (.)^ is a funetor from SubSig to Sig. 

Proof It is easy to see that if a and a' are composable subsorted signature 
morphisms, then (a o a')^ = o and that identity is preserved. □ 
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3.1.2 Models 



Subsorted models over U are the many-sorted i7^-models in which the em- 
bedding and projection functions and the membership predicates are well- 
behaved. 

For a subsorted signature U = (S, TF ^ PF ^ the subsorted models are 

ordinary many-sorted models for satisfying the following axioms: 

Identity: \/xs.em{^s),s{xs) = Xg 

Transitivity: (xg)) = emi^g^^gu (xg) for s < s' < s" 

Projection: '^Xg.pr (^g,^^g{em(^g^^gf (xg)) = Xg for s < s' 

Projection-injectivity: \/{xg^ ,yg^}.pr^^,^^^{xg^) = pr^^,^^s{yg') => Xg^ = yg> 
for s < s' 

Membership: \/xg> An{s) ^^,^^{xg>) D{pr ^g,^^g{xgf)) for s < s' 

Function- monotonicity: 

■ ■ ■ ,x^J.em^s),s"{fw,s{em{s-,},s-, (4i )>•••> (a;f„») 

for fw,s fw',s'^ where w' = (4, •••,4) and w = (si,...,s„), with 
w < w,w' for some w = (si , . . . , 5^) , and 5, s' < s" 

Predicate- monotonicity: 

V{xi , . . ), . . . , (a;|,)) 

for Pw Pw'i where w' = ( 5 '^, . . . , s'^) and w = (si, . . . , 5^), with w < 
re, w' for some w = (si , . . . , 5^) 

Proposition 3.7. In every subsorted model the following axiom holds: 

Embedding-injectivity: V{x5,^5}-e^(s), s' (^s) = (^^{s),s' {Vs) ^ Xg = yg 

for all s < s' . 

Proof Let us assume that em(^g^^gf (xg) = em(^g^^gf (yg) is satished by a sub- 
sorted model M with respect to some assignment p for {xg^yg}'^ then the 
equation pr ^^;^^^{em^g)^gf (xg)) = pr^sA,s{^'^{s),s'{ys)) is also satished by M 
w.r.t. p. By the projection axioms, both pr {^g')^g{em(^g^^gf (xg)) = Xg and 
P^{s'),si^'^{s),s' iVs)) = Vs must be satished by M w.r.t. p, since M is a sub- 
sorted model. Therefore, Xg = yg must be satished by M w.r.t. p. □ 

Notice that, as usual, the same class of models may be described by several 
different axiomatic theories that may be convenient for different purposes; for 
instance, one might wish to use a certain automatic deduction system that 
requires a specihc form of axioms. For example, we can replace the projection- 
injectivity axiom by the following axiom: 

Defined-projection: 'i{xs'}-D{pri^g,~^ g{xs')) em(^s),s> {pr i^s'),s{xs')) = Xg' 

for all s < s'. 
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This gives a set of existentially eonditioned equations (ECE) in the sense of 
Burmeister [10]. 

Proposition 3.8. Projeetions are always undefined on elements that are not 
in the image of the eorresponding embedding. 

Proof. Follows from the dehned-projection axiom. □ 

Subsorted E -model morphisms are ordinary i7^-homomorphisms, that is 
the eategory of subsorted i7-models SubMod(i7) is the full subcategory of 
Mod(i7^), whose objects are all the many-sorted models satisfying the above 
axioms. 

Therefore, all notions dehned for many-sorted models, and in particular all 
functors having many-sorted model categories as source, apply to subsorted 
models as well, via the embedding of SubMod(i7) into Mod(i7^). 

The reduet of a subsorted i7'-model along a subsorted signature morphism 
a : E ^ E' \s the many-sorted reduct along the signature morphism and 
similarly for subsorted i7Emodel morphisms. This dehnes a functor SubMod : 
SubSig^^ ^ CAT. 

Since subsorted signature morphisms preserve overloading relations, the 
reducts of subsorted models satisfy the above axioms, too, and are, hence, 
subsorted models. 

Notice that SubMod is not hnitely cocontinuous. The following coun- 
terexample is from [45]. Let E be the signature with sorts s and t and no 
operations, and let Ei be the extension of E by the subsort relation s < t. 
Then the pushout 

i: 



El ^ El 

in SubSig is not mapped to a pullback in CAT since two models of Ei that 
are compatible w.r.t. the inclusion of E may interpret the subsort injection 
differently. 



3.1.3 Sentences 



The subsorted i7-sentences are simply the many-sorted i7^-sentences. 

For a subsorted signature E^ the subsorted sentenees are the ordinary 
many-sorted sentences (as dehned in Sect. 2.1.3) for the associated many- 
sorted signature E^ . The subsorted translation of sentences along a sub- 
sorted signature morphism a is the ordinary many-sorted translation along 
(7^. That is, subsorted sentences are given by the composition of the or- 
dinary functor yielding many-sorted sentences with the functor (.)^, i.e. 
SubSen : SubSig ^ Set is dehned as Sen o (.)^. 
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A subsorted enrichment (Z\, relative to a subsorted signature E consists 
of a subsorted extension A relative to E and a set ^ of subsorted sentences 
over E yj A. 

Satisfaction over E is many-sorted satisfaction over E^ . 

Subsorted satisfaction for a subsorted signature E is ordinary many-sorted 
satisfaction for the signature Since reducts and sentence translation are 
ordinary many-sorted reducts and sentence translation, the satisfaction con- 
dition is satished for the subsorted case as well. 

Theorem 3.9. SubSig, SubMod, SubSen and \= form an institution with 
SubSig being finitely cocomplete. 

Proof. Straightforward. Cocompleteness follows from Prop. 3.3. □ 

The relationship between formula satisfaction and isomorphism is the same 
for subsorted as for standard many-sorted models. 

Proposition 3.10. Satisfaction is preserved and reflected by isomorphisms: 
if M^M' are subsorted E -models such that M = M' and fj is a subsorted 
E -sentence, then M ^ iff M' ^ if. 

Proof. Straightforward. □ 



3.2 Signature Declarations 

The rest of this chapter gives the abstract syntax of the additional subsorting 
constructs used in subsorted basic specihcations, and dehnes their intended 
interpretation, extending what was provided for many-sorted specihcations in 
Chap. 2. Unless otherwise stated, the rules for static and model semantics of 
the constructs given in Chap. 2 are the same, with the convention that the 
signatures in each rule are enriched by an implicit subsorting relation that is 
not modihed by the rules. 

As in the many-sorted case, a well-formed subsorted basic specihcation 
BASIC- SPEC of the Casl language determines an extension A to the local 
environment E together with a set of A U Z\-sentences of the form described 
in Sect. 3.1.3. This in turn describes the class of all subsorted E U Z\-models 
that satisfy those sentences. 



3.2.1 Sorts 

SORT- ITEM has three more alternatives than in Chap. 2: 
SORT-ITEM ::= ... | SUBSORT-DECL | ISO-DECL | SUBSORT-DEFN 
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Subsort Declarations 



A subsort declaration declares all the sorts, as well as the embedding of each 
subsort into the supersort, which must be a different sort. 



SUBSORT-DECL ::= subsort-decl S0RT+ SORT 

A h SUBSORT-DECL > (Z\, 

is an enrichment relative to E. 

5^ 7 ^ 5 for alH = 1, . . . , n :<s = {(s^, s) | 1 < z < n} 

(/S', TF, PF, F, <) h subsort-decl s\ . . . Sn s > 

(({si,...,s„,s},0,0,0, ^s),0) 

The hrst condition checks that each subsort is distinct from the supersort. 

Isomorphism Declarations 

An isomorphism declaration declares all the sorts, as well as their embed- 
dings as subsorts of each other. 



ISO-DECL : := iso-decl S0RT+ 



A h ISO-DECL > 

(Z\,F) is an enrichment relative to E. 



Si 7 ^ Sj for alH 7 ^ j n >2 
= {(S/, Sj) I 1 < * < n A 1 < j < n} 

{S, TF, PF, P, <) h iso-decl si . . . s„ > (({si, • • • , Sn}, 0, 0, 0, ^s), 0) 

The hrst condition checks that each sort occurs once and the second checks 
that there are at least two sorts. 

Subsort Definitions 



A subsort dehnition provides an explicit specihcation of the values of the 
subsort, stating which values of the supersort belong to the subsort by means 
of a formula with one free variable in it. 



SUBSORT-DEFN ::= subsort-defn SORT VAR SORT FORMULA 



A h SUBSORT-DEFN > (Z\, F) 
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is an enrichment relative to U. 

(S,TF,PF,F,<) = U FeS FV(F)C{v:Fj 
F h subsort-decl s > (A, 0) F U A, 0 h F^ l> (f 
F h subsort-defn s v F l> (Z\, {7^}) 

where F' is 

quantification f orall var-decl v ^^(equivalence F (membership v 5 )) 

The second condition checks that 5' is already declared, the third that the 
all variables in F but v are explicitly bound, and the fourth and the hfth^ 
conditions are equivalent to expanding the subsort dehnition into the subsort 
declaration plus an axiom stating which values of the supersort belong to the 
subsort. 



3.2.2 Datatypes 
Alternatives 



Datatype declarations have a new kind of alternative, for the embedding of 
known subsorts into the datatype. 



ALTERNATIVE : : = ... | SUBSORTS 
SUBSORTS : := subsorts S0RT+ 



F, 5 h SUBSORTS > (A, A',F) 

s is required to be a sort in F. (Z\ U Z\', F) is an enrichment relative to F. 

5^ G /S' for alH = 1 , . . . , n Fs = {(5^, 5) | 1 < z < n} 

(5, TF, PF, P, <), 5 h subsort 5i . . . 5 ^ > ((0, 0, 0, 0, 0, 0), {} 



The hrst condition checks that the subsorts are declared elsewhere. 

Note that this kind of alternative does not contribute a constructor, in 
contrast to the other kinds - the subsort embeddings are treated as implicit 
constructors, see below. 

^ Actually, if free variables different from v appear in F, this condition cannot be 
satisfied, so that the third condition is superfluous and required only for stressing 
the point. 
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Free Datatype Declarations 



The embeddings of subsorts are treated as implicit constructors. 

The rule for free datatypes given in Sect. 2.3.4 has to be modihed to treat 
the embedding of subsorts as constructors as well. 

Thus, the rule: 



i: h DATATYPE- ITEMS > (Z\, A' 

(5, TF, PF, P) = U {S', TF', 0, F') = Z\ S" = S [J S' 

F h free-datatype DATATYPE- ITEMS > 

(Z\ U Z\', F U {injective {fw,s) \ ^ ^ FinSeq{S"), s e S" , f e TF'^ 

U I disjoint-ranqesi c, q^' s) 

\w,w' e FinSeq{SV,se S" , f e TF’^^,,g e TF’^,^, 
such that w ^ w' OT f ^ g} 

U {undefined- selection{fw s^9{s) s') 

U {{S', complete{TF' , FinSeq{S") x F"))}) 



is replaced by: 



F h DATATYPE- ITEMS > {A, A',F),W 
{S, TF, FF, P,^ = F {S', TF', 0, P' , -() = A S" = S US' 
F=TF'U {{{s),s') em\s-<s'} 

F h free-datatype DATATYPE- ITEMS > 

{A U A' ,F U {injective {fqju^s) \ ^ FinSeq{S"), s G S", f G TF'^ 

U {disjoint-ranges{fuj^s^ 9w' ,s) 

\vu,vu' e FinSeq{S"),s G S" , f G Fy,^s,9 ^ ^w',s 
such that w w' OT f g} 

U { undefined- selection { fqjn s, a/c\ .A 

U {undefined- selection{em^sff^ s^9{s) s') 

\s" ^seS",s" ^s, 

/^,5 ^ D^{W),g^s),s' ^ W{fqqj^s)} 

U {{S', complete{F , FinSeq{S") x S"))} ) 

where injective, disjoint-ranges and undefined- selection are dehned as in 
Sect. 2.3.4. 

Theorem 3.11. Consider a declaration free -datatype DATATYPE- ITEMS, a 

signature F and a model class j\4 over F , and suppose 

F h DATATYPE- ITEMS > {A, A',F),W 
F h f ree-datatype DATATYPE- ITEMS > {AU A', F') 

such that DATATYPE- ITEMS fulfills the follovuing conditions (all referring to 
fully qualified symbols): 
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• The sorts in A ( and hence the constructors in A and the selectors in A! ) 
are not in the local environment U; 

• Any selector in A' is total only when the same selector is present in all 
ALTERNATIVES for that sort; 

• Each constructor in A and each selector in A' is in the overloading relation 
of E U AU A' only with itself; and 

• Distinct sorts in A have no common subsort in E U AU A' . 

Let C be the full subcategory of Mod(i7 U AU A') containing those {E U 
A U A')-models M" such that M" ^ for all ip eT, and let A4' and M" be 
the {E VJ AVJ A') -model classes 

= {{EUAU A')-model M' 

I ^ M and M' e C is free over 

w.r.t. \e^e\ja\jA' • C Mod(i7)} 

M" = {{EUAU A')-model M' 

I M'\e^euauA' ^ M and M' ^ for all fj' G T'} 

Then M' = M". 

Proof. Employing the notation of the above rule, let us use S' for the sorts in 
A and F for the functions from A and the embeddings relative to the subsorts 
explicitly given in A (that is, for the constructors). 

Let us hrst show that Ai" C Aih 

It suffices to show that every model M G Ai" ^ satisfying the axioms in 
T' ^ is free w.r.t. .\e^e\ja\jA' • C Mod(i7), that is, that it belongs to C 
and that any homomorphism h from its i7-reduct to the i7-reduct of a model 
N ^ C extends uniquely to a homomorphism from M to on the overall 
signature. 

Since, by construction, T Cpp Ai" C C hence M ^ C. Thus, we only have 
to prove the existence of the E U AU Z\'-homomorphism extending h. 

As the sorts in S' are new in the environment, to extend the homomor- 
phism we have to give the new components hg for each s ^ S' . 

Because of the sort-generation constraint in T' (see the last axiom of the 
rule), for every element a in the carrier of sort s (with s G 6"), there is a term 
t = f If ... An) containing only function symbols from F and variables of 
sorts not in S' such that |t]^= a for some assignment p into M\e^euauA' • 
Let us show that such a term t is unique (up to variable renaming). Since 
t = /(ti, . . . An) and |t]^= a, we have a = /^(ai, . . . ,a^) for some f ^ F 
and ai = Moreover, 

• because of the disjointness axioms in T' the leading symbol is unique 

• because of injectivity axioms in T' the argument tuple is unique 

For each G sf^ ^ if Si ^ S' ^ then ti is a variable; otherwise, we can recursively 
apply this argument to (and U). 

Therefore, for each s ^ S' and each a G there exists a unique term 
ta containing only function symbols from F and variables of sorts not in S' 
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such that |ta]p= CL for some assignment p into Hence, we can 

(inductively) dehne hg as hs{a) = hs{f^{ai, . . . , a^)) = /^(/z(ai), . . . , h{an)) 
and since the decomposition is unique, this equation yields a function. More- 
over, such hg is the unique possible candidate homomorphism because it is 
dehned by the homomorphism condition itself. 

Finally, h satishes the homomorphism condition for each function symbol 
/ in ^ where U Z\ U Z\', because: 

• if / is a function symbol in as /z is a subsorted i7-homomorphism, 
that is a many-sorted i7^-homomorphism; 

• if / belongs to F, by construction; 

• if / belongs to A' (i.e. is a selector), because selectors in M are dehned 
only on the image of their constructor(s), where their value is hxed by the 
constructor /selector axioms in F, so that they have to be dehned in N as 
well (with compatible values); and 

• if / is a projection, because projections are dehned only on the image of 
their embeddings and their value is hxed by the axioms required from M 
and N to be subsorted models. 

The homomorphism condition for predicates is trivially fulhlled, since A and 
A' do not contain any new predicates, and for those in we already know 
that it holds^. 

Vice versa, let us show now that A4' let us hx an arbitrary model 

M' G A4' . Let us consider the V-model M = M'\z; and directly build an 
extension M", satisfying the axioms of F'. Thus, because of the previous point, 
such an extension M" is free. Then, as M' and M" are isomorphic, being both 
free models over M, and isomorphic models satisfy the same formulas, we get 
that M' satishes the axioms of W' . The extension M" is built as follows: 

• For all s ^ S' we (simultaneously) inductively dehne the carriers to consist 

of formal applications of embeddings and constructors, that is elements of 
the form /(ai, . . . ,a^) where / G and G sf^ if Si ^ S' and 

otherwise G sf^ . Thus, the may be formal applications as well as 
elements of M. 

• The interpretation of functions and predicates from is as in M. 

• The interpretation of embeddings and constructors from A yields the for- 
mal interpretation (so the resulting model is generated by F, and the 
axioms of injectiveness and disjointness hold). 

^ The homomorphism condition for membership predicates, possibly introduced by 
the new subsorting relations in Z\, is obviously satished, because of the axioms 
required from M and N to be subsorted models that dehne the validity of the 
membership predicate. 
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• The interpretation of any selector from A! is defined for values in the im- 
age (s) of its corresponding constructor (s) so that the selector-constructor 
axioms are satisfied^. For all other values it is undefined (so that the ax- 
ioms concerning undefinedness of selectors are satisfied). 

• Analogously, the interpretation of projections is defined only on the image 
of their embeddings (and their composition yields the identity) and the 
membership predicates are true only on the image of the corresponding 
embedding (so the axioms required for M" to be a A U Z\ U Z\'-model are 
satisfied). 

Finally such construction yields a subsorted model M" . The identities required 
for overloaded symbols are satisfied for the functions and predicates in A, 
because M is the reduct of a subsorted model M' on the overall signature, 
and they are satisfied for the constructors and selectors in Z\ U Z\', because 
for them the overloading relation is the identity. Moreover, the transitivity 
axioms are satisfied because the alternatives being sorts do not have common 
subsorts. □ 

Below we give an example of a typical free datatype declaration and discuss 
some ways in which specifications may accidentally become inconsistent. 

Here is an example of a free datatype declaration where all alternatives 
are sorts that are declared beforehand, which corresponds to a declaration of 
a disjoint union type: 

free type Vehicle ::= sort Car \ sort Bicycle 

The semantics of the free datatype declaration is the following enrichment 
(relative to a signature E containing the two sorts Car and Bicycle): 

(Z\, {Vx: Car^ y '.Bicycle .^(^ctti ^ Vehicie{‘^) ~ {Bicycle) , Vehicle {y)) 1 

\/x: Car^ y:Bicycle .^(^CTTI (^^icycle) ^ Vehicle{^) (Car), Vehicle {y))i 

({ Vehicle}, F, idjjuA)} 

where A is the signature extension (relative to E) containing the sort Vehicle, 
no function symbols or predicate symbols, and the subsort relation < which 
is the refiexive and transitive closure of {{Car, Vehicle), {Bicycle, Vehicle)}. 
Moreover, F contains the two embedding function symbols emi^car), Vehicle 
and cm ^Bicycle) .Vehicle- The first two sentences are from the disjoint-ranges 
condition; they are equivalent. The third sentence is a sort generation con- 
straint which requires each value of sort Vehicle to be produced by either 
e-m(car),Vehicie{x) or em (Bicycle), Vehicieiv) for some assignment of a value of 
sort Car to x or a value of sort Bicycle to y, respectively. Since there are 
no explicit constructors and selectors, there are no injectivity sentences (but 
embeddings that play the same role as constructors are instead required to be 

^ There are no contradictions in these axioms, as elements built from different 
constructors are different because of the disjointness axioms in F , and the same 
selector cannot belong to two different components of the same alternative. 
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injective by the axioms for subsorted models), no sentences relating selectors 
to their constructors (but projections that play the same role as selectors are 
instead related to their embeddings by the axioms for subsorted models) and 
no sentences expressing undefined- selection conditions (but the disjoint-ranges 
conditions and the axioms for subsorted models ensure that it is undehned to 
apply a projection function to a value generated by an embedding function 
from a different sort, e.g. '^x:Car.^D{pr (^y^^i^i^^^Bicycie{em{car),Vehicie{x))))- 
Notice that if, after a correct dehnition of a free datatype 5, other basic 
items are added to the specihcation that modify the overloading relation or 
the subsort relation, then the resulting overall specihcation may be inconsis- 
tent because the explicit axioms of the free datatype and the implicit axioms 
for subsorted models may conhict. To be more specihc, the disjointness axioms 
require the constructors and embeddings of a free datatype to have disjoint 
images, but at the same time some applications of its constructors and embed- 
dings may be required to yield the same value by the implicit monotonicity 
axioms or transitivity axioms for subsorted models. This may happen if addi- 
tional basic items cause a constructor to enter the overloading relation with 
a function that has as range sort a subsort of one of the alternatives of the 
free datatype, or if a common subsort of two alternatives (sorts) of the free 
datatype is added. 

Let us consider two instances of this kind of problem. The hrst case ex- 
emplihes the danger of modifying the subsorting relation. The second one 
demonstrates how problems may arise from an extension of the overloading 
relation. 

Consider the following specihcation of the union of two sorts si and 5^: 
sorts 5i, 52; 

free type Union ::= sortsi \ sort s 2 

Now we add a sort representing an intersection of the two sorts, and declare 
a constant a of that new sort to guarantee that the intersection is non-empty: 

sort Intersection < Intersection < 52; 
op a : Intersection 

Then 

^^(si ), Unioni^'^ {Intersection) , Si {^ {), Intersection)) 

is equal to 

(s2 ) , Union { {Intersection) ,S2 {^ {), Intersection ) ) 

as both are equal to 

era {Intersection) , Union {^ {), Intersection) 

due to the transitivity axioms for subsorted models. However, the images of 
em{s^)^Union cm ^Q^YUnion required to be disjoint by the axioms of the 
free datatype. Hence, the resulting specihcation is inconsistent. 

Now, consider the following specihcation of non-empty lists of elements 
taken from a sort s: 
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free type NEList ::= sorts \ cons {first : s; rest : NEList) 

Now, let us refine the sort s into non-empty lists of elements from another 
sort Elem: 

free type s ::= sort Elem \ cons{first : Elem] rest : s) 

Then, if e is any term of sort Elem^ we have that 

cons (^s, NEList), NEList {Elem), s{^)i {Elem) , NEList {^)) 

and 



{s) , NEList {Elem,s) ,s (^5 ^'^{Elem),s (^))) 

are equal, because of the function-monotonicity axioms for subsorted models. 
However, the images of con s^^, NEList), NEList and em^^), NEList are required to 
be disjoint by the axioms of the free datatype. Hence, the resulting specifica- 
tion is inconsistent. 

Notice that both of these examples are quite artificial and, though the 
technical problem may be subtle, intuitively the inconsistencies arise from a 
change of the expected meaning of the given free datatype specifications. 

Consider for instance the first example. Since we are requiring the datatype 
Union to be free, we are actually describing the disjoint union of the sorts 
Si and 5 ^, as with Vehicle above. Thus, adding a non-empty sort for their 
intersection is actually an attempt to change the understanding of what the 
union is and hence correctly results in an inconsistency. 

Analogously, the second example is based on a naive refinement of the sort 
s where the problem comes from using the same name for the constructors of 
the two levels of lists. Due to the axiom of function monotonicity, the choice of 
the same name corresponds to requiring that the two constructors represent 
the same function on common arguments (up to embedding). This, in turn, 
means that we are describing (in an overly complex way) lists of elements of 
sort Elem^ instead of lists of lists, as one would expect from the structure of 
the specification (and as it would be if we had used a different name for the 
lower level constructor). 



Sort Generation 



The treatment of a sort generation SORT- GEN is as in Sect. 2.3.5 except that 
the embeddings of subsorts are treated as implicit constructors. 

In order to treat the embedding operations as declared operations, the 
following rule, given in Sect. 2.3.5: 
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U h SIG-ITEMSi > 

i: U Z\i U U • • • U Z\n-1 U A'^_^ h SIG-ITEMSn > (An, 

(S, TF, PF, P) = Z\ = Z\i U • • • U Z\n A' = A[U^^^UA'^ 

(S', TF', PF', P') = FUAUA' F 7^ 0 
F h sort-gen SIG-ITEMSi . . . SIG-ITEMS^ > 

(Z\UZ\',Fi U---UFnU{(F, compF^e(FFUPF,FmFe^(F') x F'))}) 

is replaced by: 



F h SIG-ITEMSi > (Z\i,Z\;,Fi) 

F U Z\i U U • • • U An-i U A'^_^ h SIG-ITEMSn > (An, A'^,^n) 

(S, FF, PF, P, <) = Z\ = Z\i U • • • U Z\n Z\' = U • • • U A'^ 

(S', TP', PF', P',<') = PUAUA' F ^ 0 
TP" = FF U {(( 5 ), s')^ em\s< F} 

F h sort-gen SIG-ITEMSi . . . SIG-ITEMSi > 

(Z\UZ\',Fi U---UFiU{(F, compF^e(FF"uFF,FmFe^(F') x S'))}) 

Note that projections, like selectors, are not included in the set of func- 
tions of the sort generation constraint, since the axioms of subsorted models 
guarantee that projections can never generate new elements. 



3.3 Axioms 

3.3.1 Atomic Formulas 

ATOM has one more alternative than in Chap. 2: 

ATOM : : = ... | MEMBERSHIP 

As for many-sorted specihcations, an atomic formula is well- formed (with 
respect to the current declarations) if it is well-sorted and expands to a 
unique atomic formula for constructing sentences of the underlying insti- 
tution - but now for subsorted specihcations, uniqueness is required only 
up to an equivalence on atomic formulas and terms. This equivalence is the 
least one including fully-qualihed terms that are the same up to prohles of 
operation symbols in the overloading relation ~ p and embedding, and fully- 
qualihed atomic formulas that are the same up to the prohles of predicate 
symbols in the overloading relation and embedding. 

The relaxation of the well-formedness requirement for subsorted specih- 
cations means that the rule for well-formedness of atomic formulas given in 
Sect. 2.5.3 has to be modihed, requiring the existence of a unique expansion 
up to the equivalence relation dehned below. 
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Thus, the following rule 

there is a unique (p such that \~ ATOM > p 
X,X h ATOM > p 
X,X^ ATOM qua FORMULA > p 

is replaced by 

p p^ for all p' such that X^X \~ ATOM > p' 

X,Xh ATOM > p 
i:, X h ATOM qua FORMULA > p 

where ~ is dehned below. In the hrst premise - which is equivalent to 
yp'.{X,X h ATOM > p' implies p ~ p') - the static semantics of ATOM oc- 
curs in a negative position. This potential problem can be eliminated in the 
same way as in the many-sorted case. 

The equivalence between fully-qualihed terms is the congruence generated 
by the following axioms: 

em(s)^s{t) ~ t 

for s < s' < s" 

Pr{s'),s{em^s)^s>{t}) ~ t for s < s' 

(4i)> • • • > e"* {«,.).«„ (a;?„))) ^ 

for fw,s fw',s’^''JJ= («!>• • ■^Sn),w' = (s'l, . . . ,s:^),with 
w < w,w' foT w = (si, . . . , 5n), and 5, s' < s" 

The equivalence between atomic formulas is the natural extension of the 
equivalence between fully qualihed terms and is inductively dehned by: 

Equivalence: 

y - y' y' - 

(f ~ (f" 

Replacement of equivalent terms: 

t ~ t' sort(t) = sort(t') 

WXW) 

ti ~ t'l t2 — t'2 sort{ti) = sort(t2) = sort(t'i) = sort(t'2) 

ti = t 2 - 1 ; = t'2 

ti ~ t'l t2 — t'2 sort{ti) = sort(t2) = sort(t'i) = sort {t'2) 

tl=t 2 - n = t'2 





‘p-f r -p 
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t ~ t' sort{t) = s' = sort{t') s < s' 

*«(«){*') 

ti ~ t' sort{ti) = Si = sort{t'^) for 1 < i < n w = {si, , Sn) 
Pw{ti,...,tn) ^ ^ ^ ^ ,t'^) 

Embedding and projection: 

sort(t) = s = sort(t') s < s' 

^ t = t' 

sort{t) = s = sort{t') s < s' 

^ t = t' 

Pr{s'},s{t') -Pr{s")A^") 

sort{t') = s' sort{t") = s" s < s' s < s" 

*«(«)(*') (*') - 

sort{t) = s s < s' s < s" 

D{em.(s),s'{t)) - D{em(s),s"{t)) 

Predicate overloading: 

sort{ti) = Si pyj ~p p'^, 

w = {si,...,s„) w' = {s[,...,s'„) {si,...,s„) <w,w' 

{ti), • • • , e"i{s„),s„ (*»)) - P'w'{^'<^('Si),s[ {h), ■■■, {tn}) 

Membership 

A membership formula is well-sorted if the term is well-sorted for a supersort 
of the specihed sort. It expands to an application of the pre-declared predi- 
cate symbol for testing values of the sort of the given term for membership 
in the image of the embedding of the given sort. 



MEMBERSHIP : : = membership TERM SORT 

(5, TF, PF, P, <), X h TERM > t sort(t) = s' s < s' 
(/S', PP, PP, P, <), X h membership TERM s > (t) 
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3.3.2 Terms 

Term formation is extended by letting a well-sorted term of a subsort be 
regarded as a well-sorted term of a supersort. 

(5, TF,PF,P, <),X hTERM>t sort{t) = s s < s' 

(P, TF,PF,P,<),X hTERM> em^s),s'{t) 

Analogously for sorted terms we have 



(P, TF,PF,P,<),X hTERM>t sort{t) = s s < s' 
(P, PP, PP, P, <), X h sorted-term TERM s' > (t) 



Casts 



Terms have one more alternative, representing the (partial) projection of 
values from a supersort onto a subsort. A cast term is well-sorted if the term 
is well- sorted for a supersort of the sort. It expands to an application of 
the pre-declared operation symbol for projecting the sort of the term to the 
given sort. 



TERM : : = ... | CAST 
CAST : : = cast TERM SORT 



(P, PP,PP,P, <),X h TERM> t sort{t) = s' s < s' 
(P, TF,PF,P,<),X h cast TEm s > pr 
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Structured Specification Semantics 



The semantics of a well-formed structured specification is of the same form as 
that of a basic specification: a signature U together with a class of i7-models. 
While the model class of a basic specification can be characterized by a set of 
sentences, this is not possible for structured specifications, due to the presence 
of constructs such as hiding and freeness. Hence, the semantics of structured 
specifications is essentially based on model classes. 

The structure of a specification is not refiected in its models: it is used 
only to present the specification in a modular style. (Specification of the ar- 
chitecture of models in the CoFI framework is addressed by architectural 
specifications, see Chap. 1:5, with the semantics given in Chap. 5.) 

Within a structured specification, the current signature may vary. It is 
also called the local environment. On the other hand, the current association 
between names and the specifications that they reference is called the global 
environment. 

For the semantics of structured specifications (in particular, those involv- 
ing hiding) the axiom of choice is assumed. Note that hiding is as expressive 
as second-order existential quantification, the semantics of which may depend 
on properties of the background set theory, like the axiom of choice. For in- 
stance, one can express the proposition that every vector space has a basis as 
a view in Casl (see Chap. V:9), and indeed the well-formedness of this view 
is equivalent to the axiom of choice. 



4.1 Structuring Concepts 

The Casl structuring concepts and constructs and their semantics do not 
depend on the choice of institution used to write basic specifications. This 
means that Chaps. 2 and 3 are orthogonal to Chap. 4 (and also to Chaps. 5 
and 6). Therefore, Casl basic specifications as given in Chaps. 2 and 3 can 
be restricted to sublanguages or extended in various ways without the need 
to reconsider or to change Chaps. 4, 5, and 6. 
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The concepts defined in Chaps. 2 and 3 lead to a Casl institution, here 
formalized as an institution with qualified symbols (Sect. 4.1.1). Institution 
independence of the semantics of structured specihcations is achieved by in- 
troducing a vocabulary of derived notions (Sect. 4.1.2) that can be dehned 
over an arbitrary institution with qualihed symbols, and writing the semantics 
in terms of this vocabulary. At various places, we detail what these notions 
mean in the Casl institution. 

The derived notions are used mainly in the computation of signature mor- 
phisms out of symbol maps, which is addressed in Sect. 4.1.3. Signature mor- 
phisms (and the corresponding reducts on models) occur at many places in 
the semantics of structured specihcations. For instance, hiding some symbols 
in a specihcation involves a signature morphism that injects the non-hidden 
symbols into the original signature; the models, after hiding the symbols, are 
the reducts of the original models along this morphism. Translation goes the 
other way: the reducts of models over the translated signature back along the 
morphism give the original models. Casl uses symbol maps to denote signa- 
ture morphisms; the semantics of symbol maps is of course institution specihc 
(Sect. 4.5). 

Finally, in Sect. 4.1.4, we slightly modify (in an institution independent 
way) the institution, equipping so-called extended signatures with a set of 
symbols as a further component. 

Let us stress that, though the following details are a bit complicated, once 
the reader has accepted the concept of signature unions and has learned that 
signature morphisms are generated by maps between symbols in a more or less 
expected way, the semantics of structured and architectural specihcations may 
be understood in terms of an arbitrary institution, with the qualihed symbol 
structure put aside. For the hrst reading of this chapter, it may therefore be a 
good idea to continue with the institution independent structuring concepts 
in Sect. 4.1.5, and refer to the sections before that only when needed. 



4.1.1 Institution Independence and the Casl Institution 



The Casl structuring concepts and constructs and their semantics do not 
depend on a specihc institution; hence, they are given here in an institution- 
independent way. 



In order to achieve institution independence, below we introduce a min- 
imal vocabulary of notions required for the semantics of structured spec- 
ihcations. Together they form the Casl institution with qualified symbols. 
In order to change the framework of basic specihcations, one just has to 
change the institution with qualihed symbols. While Chaps. 2 and 3 are com- 
pletely institution-specihc, in Chap. 4 we explieitly indieate those parts that 
are institution- speeifie. These are: 
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• the definition of the Casl institution with qualified symbols; 

• some propositions about what some institution-independent derived no- 
tions mean in the Casl institution (Props. 4.1, 4.2, 4.4, 4.5, and 4.6); 

• the semantic rule for treating a basic specification as a structured specifi- 
cation (see page 204); and 

• some of the rules for symbol lists and maps in Sect. 4.5. 

A more formal treatment of this issue can be found in [39]. 

We now come to the components of the Casl institution with qualified 
symbols. We first recall the components of the Casl institution with symbols 
that have been introduced in Chaps. 2 and 3. 

Category of signatures and signature morphisms: A category SubSig 
of signatures with subsorting was introduced in Chap. 3. 

Sentences: A sentence functor Sen: Sig^Set was introduced in Chap. 2, 
see page 135, and extended to subsorted signatures via composition with 
the functor (.)^: SubSig ^Sig, yielding a functor SubSen: SubSig^ 
Set. 

Models: A model functor Mod: Sig^^ ^ CAT was introduced in Chap. 2, 
see page 130, and extended to subsorted signatures via composition with 
the functor (.)^ : SubSig ^Sig and further restriction by axioms, yield- 
ing a functor SubMod: SubSig^^ ^ CAT. 

Satisfaction: A satisfaction relation ^ |Mod(A)| x Sen(A) was intro- 
duced in Chap. 2, see page 135, and extended to subsorted signatures, 
models and sentences via composition with the functor (.)^ : SubSig ^ 
Sig. 

Signature symbols: A set of signature symbols SigSym and a faithful func- 
tor |.| : Sig ^ Set giving, for each signature A, a set of signature symbols 
1^1 ^ SigSym^ and for each signature morphism a: a translation 

of signature symbols \a\: | A| ^ | A'|, were introduced in Chap. 2, pages 126 
and 128, and extended to subsorted signatures in Chap. 3, page 171. 

We now extend this institution with more notions, mainly regarding the 
computation of signature morphisms out of symbol maps. 

Symbols: 



k G SymKind = {implicit^ sort ^ fun ^ pred} 



SY e Sym = 

5 G 



fws ^ 
fws £ 
Pw C 
(/c, Ident) G 



Sort l±) 

QualFunName l±) 
QualFunName l±) 
QualPredName l±) 
[SymKind x ID) 
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Identifiers can be regarded as symbols using the injection 

IDAsSym: ID^Sym 
defined by IDAsSym{Ident) = {implicit ^ I dent). 

For simplicity, we regard SORT- ID as a subset of ID, although there is only 
an embedding between the two sets. The embedding maps WORDS to id 
WORDS and comp-sort-id WORDS ID+ to id (comp-mix-token ID+). 
Factorization of signature symbol functor: There is a partial function 
SymAsSigSym : Sym SigSym^ such that the object part of the signature 

symbol functor |.|: SubSig ^ Set can be can be factorized through a 
symbol function 

||.|| : : |SubSig| ^ |Set|, 

such that ||T|| C Sym and for each U G |SubSig|, SymAsSigSym{\\U\\) 
is dehned and equal to \U\. 

We dehne SymAsSigSym as follows: 

SymAsSigSym{s) = s 5 G Sort 

SymAsSigSym{fl^g) = f^s fws ^ QualFunName 

SymAsSigSym{f^g) = f^js fws ^ QualFunName 

SymAsSigSym{pw) = Pw Pw ^ QualPredName 

SymAsSigSym{k^ Ident) = undefined 

li E = (/S', TF, PF, F, <), we dehne ||F|| C Sym as follows: 

ll^ll = I ws G FmSeq{S) X F, / G FF^J 

u {/L I e FinSeq{S) x S,f & PF ws} 

U {pw I w G FinSeq{S),p & Pw} 

Signature symbols matching symbols: The matching relation 

matches C SigSym x Sym 

between signature symbols and symbols is the least relation satisfying 

• s matches {implicit^ 5) for s G Sort^ f^s matches {implicit^ f) for f^s ^ 
QualFunName and / G ID, and matches {implieit^p) for G 
QualPredName and p G ID, 

• s matches {sort^s) for s G Sort^ f^s matches {fun^ f) for f^s ^ 

QualFunName and / G ID, and p^ matches {pred^p) for G 

QualPredName and p G ID, 

• s matches 5 for 5 G Sort^ 

• fws matches for fws ^ QualFunName^ 

• fws matches for fws ^ QualFunName^ 

• Pw matches pw for pw G QualPredName. 

Names of signature symbols: There is a function nameSigSym ID as- 
signing a name name(SSY) to each signature symbol FFT, such that, 
whenever name(SSY) is dehned. 
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SSY matches IDAsSym{name{SSY)) 

It is defined as follows: 

name{s) = 5, for s G Sort^ 

. „ . f f, if fws C QualFunName and f G ID 

name(f^s) = S j n i A • , 

^ ^ [ undefined, otherwise 

.X f n, if G QualPredN ame and n G ID 

= I undefined, otherwise 

Note that name is defined on the actual signature symbols of a signature, 
since these exclude the special embedding, projection and membership 
symbols introduced in Sect. 3.1.1, and the latter are the only ones that 
are not based on an ID. 

Empty signature: The empty signature, denoted by 0, has been defined in 
Sect. 1.1. We define = Mod(0). consists of exactly one object. 
Signature unions: The union of signatures has been defined in Sect. 3.1.1, 
see page 170. The union of Yi and i 72 , written Yi U i 72 , comes with two 
injections ^z’icz’iuz ’2 ^z’ 2 cz’iuz’ 2 - 

In the Casl institution, unions are always defined, but in other frame- 
works, this need not be the case. In the rules for the semantics below, 
when we use a union inside a condition (e.g. within the premises of a rule) 
it is implicitly assumed that the definedness of the union is added with a 
conjunction to this condition (e.g. yielding an extra premise). 
Generating signature morphisms: A signature morphism 

a= (o-^, ACo-f'Co-f') : (S,TF,PF,P,<) (S' , TF' , PF' , P' , <') 



is said to be generating if 

• |cr| is surjective, 

• a detects totality (i.e. f' G implies that there is some ws with 

a^{ws) = ws and some / G TFy^g with (/) = /')-, and 

• <' is the least pre-order on S' satisfying 

< 7 ^( 51 ) <' (y^{s2) if Si < 52. 



It can be shown that generating signature morphisms a: Ei^ E 2 are finals 
that is, any function h: IA 2 I ^ IA 3 I is a signature morphism provided that 
ho\a\: is'. 

It is possible to replace the Casl institution with a different one, provided 
that it comes equipped with the components listed above. 



4.1.2 Derived Notions 

We now introduce, in an institution independent way, some further notions, 
derived from those introduced above, that are needed for the semantics of 

^ Here, h: IT 2 I ^ IT 3 I is said to be a signature morphism if there is a signature 
morphism 6: E 2 ^E?> with |^| = h. 
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structured specifications. At various places, we detail what these notions mean 
in the Casl institution. 

Subsignatures, signature inclusions and extensions: We say that a sig- 
nature morphism A ^ A' is a signature inclusion if |^| is an inclusion 
(of \E\ into If there exists a signature inclusion from E to A', we 

call E a subsignature of E' and write E C E' . Notice that in this case 
the signature inclusion is unique, and we denote it by le(ze'- is then 
called an extension of E. 

Reducts along signature inclusions: Given a subsignature A of a signa- 
ture E' and a A'-model M , we write M\e for Similarly, given 

a A'-homomorphism h: M ^ M ', we write H\e for 
Final signature unions: A sink is a pair of morphisms with common 
codomain. A sink (ai : E\ E,a2i E2 E) is called finals if for 
each function h: \E\ |A'|, h is a signature morphism^ provided that 

ho |( 7 i I : \Ei I ^ \E'\ and ho |a2| : |N’2| ^ \^'\ are. A union is said to be 
final if the sink consisting of the two inclusions is hnal. 

Proposition 4.1 (CASL-specific). Let =f and =p denote the transi- 
tive closures of the overloading relations and ^p, respectively. Then 
signature morphisms preserve =p and =p. 

Proof. By induction on the transitive closure, using the fact that signature 
morphisms preserve ^p and as basis for the induction. □ 

Proposition 4.2 (CASL-specific). For a union Ei U E2, the follovuing 
are equivalent: 

1 . The union is final. 

2 . The relation of E\ U A2 is the transitive closure of the union 

of the relations and (and similarly for =p). 

Proof. ^( 2 ) ^ ^( 1 )' We here argue for =p only, the argument for =p 
being entirely analogous. Let be the transitive closure of the union 
of the relations and Suppose without loss of generality that 

f : w ^ s / : w' ^ s' but not f : w ^ s / : w' ^ s' . Extend 

El U A2 to A by adding, for any vu" , s" such that / : w" ^s" =p f : re ^ 5, 
an operation symbol g: vu" ^ s" not in Ei U E2. Let a: |Ai U A2I ^ |A| 
be the identity, except that / : vu" ^ s" is mapped to g: vu" ^ s" for any 
/: vu" ^s" =F f: vu^s. Since a{f: vu' ^ s') = f : vu' ^ s' g: vu^s = 
cr{f : re ^5), a does not preserve the overloading relations and therefore 
is not a signature morphism. But a o leiCEiUU 2 a o iE2CEiUU2 
signature morphisms (any two function symbols in the overloading relation 
of El U E2 are either both =p f: vu^s or both ^p f : vu^s). Thus, the 
union is not hnal. 

^ See the previous footnote. 
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(2) ^ (1): In order to show finality of the union, consider a function 
a: \Ui U i72| ^ |i7| such that a o ijj^cu^uU 2 and a o le 2 CEiUE 2 are sig- 
nature morphisms. Now the subsorting relation and the transitive clo- 
sure of overloading relations are the transitive closure of the respective 
component-wise union. Therefore, a preserves these relations (and also 
profiles of symbols) because cr o ^^^cz’iuz ’2 and cro ^^ 2 CZ’iUZ ’2 do so. Thus, 
(7 is a signature morphism. □ 

Signature symbol maps: A signature symbol map is a binary relation on 
the set of signature symbols^: 

h G SigSymMap = FinSet{SigSym x SigSym) 

Fully qualified symbols: A symbol SY is said to be fully qualified if SY e 
Dom{SymAsSigSym)) . 

Symbol maps: 

r G SymMap = Set{Sym x Symfi 

Symbol map induced by a signature morphism: Given a signature 
morphism a: ^ A 2 , the symbol map induced by a is defined to be 

||a|| = {(5 'Ti,5'T2) I SY, G ||r,|| fully qualified for i = 1,2, and 
\a\{SymAsSigSym{SYi)) matches SY 2 } 

Signature morphisms matching symbol maps: Given a signature sym- 
bol SSY and a symbol map r, we say that SSY is not directly mapped by 
r if SymAsSigSym~^ {SSY) H dom{r) = 0. 

Given a signature morphism a: Y and a symbol map r C Sym x Sym^ 
we say that a matches r if: 

• for all {SY, SY') G r with SY fully qualified, we have SY G \\Y\\ and 

\a\{SymAsSigSym{SY)) matches SY' , and 

• for all {SY, SY') G r such that SY is not fully qualified, 

- 

- there exists some SSY G \Y\ not directly mapped by r that matches 
SY, and moreover 

- for all such SSY G \Y\ not directly mapped by r and matching 
SY, we have |cr|(5'5'T) matches SY' . 

Signature morphisms leaving names unchanged: Given a signature 
morphism a: Y ^ Y' and a symbol map r C Sym x Sym, we say that 
a leaves names unchanged outside r if for any SSY G \Y\ matching no 
SY G dom{r), name{\a\{SSY)) = name{SSY). 

Compatibility of signature morphisms: A pair of signature morphisms 
(7i : Yi ^ Y'-^ and ( 72 : Y 2 ^ Y '2 are compatible if their signature symbol 
maps |(7i| and \a 2 \ coincide on the intersection |Ai| H IA 2 I of their domains 
(i.e., graph{\ai\) U graph{\a 2 \) is a function). 

^ A motivation of this choice can be found in [39]. 

We also need infinite symbol mappings because of the function Ext, see page 196. 
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Unions of signature morphisms: Given a pair of signature morphisms 
(7i : ^ and ( 72 : ^ 2 ^ ^ 2 ^ 9 '^o.ph{\cri\) U graph{\a 2 \) is (the graph 

of) a signature morphism from Ui U U2 to U[U U'2^ then ai U a2 is dehned 
to be this signature morphism (it is unique since |.| is faithful), otherwise, 
it is undehned. 




Proposition 4.3. Given signature morphisms and ( 72 : i ^2 ^ 

U 2 , eonsider the following eonditions: 

1. UiU U 2 is final and ai and G 2 are eompatible. 

2. (7i U (72 is defined. 

3. (7i and G 2 are eompatible. 

We have that (1) ^ (2) ^ (3) (but the eonverse implieations do not hold 
in general). 

Proof. (1) ^ (2): Compatibility of ai and (72 means that graph{\ai\) U 
graph{\a 2 \) is a function. By hnality of the union Ui U i72, it is also a 
signature morphism. 

(2) ^ (3): If (7i U (72 exists, graph{\ai\) U graph{\a 2 \) is a function. Thus, 
a I and (72 are compatible. □ 

Extension of symbol maps: There is a function 

Ext: FinSet{Sym x Sym) ^ Set{Sym x Sym) 

giving for each symbol map r C Sym x Sym an extension Ext(r) C Sym x 
Sym of r, i.e. r C Ext(r). At this point, we take Ext(r) to be just r. 
This will be modihed in Sect. 4.6 when giving the semantics of compound 
identihers. 



4.1.3 Signature Morphisms 



A set SSYs of signature symbols in \E\ determines the inclusion of the 
smallest subsignature of E that contains these symbols. (When an 

operation or predicate symbol is included, all the sorts in its prohle have to 
be included too.) 

A subsignature E' of a signature E is said to be full if every subsignature 
of E with the same set of names as E' is a subsignature of E' . 
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We call a set of signature symbols SSYs C \U\ closed in U if there is a 
subsignature E' of E with the set of signature symbols SSYs^ i.e. such that 
|i:'| = SSYs. 

Given a set SSYs C \E\^ if there is a unique full subsignature E' of E 
such that \E'\ is the smallest set containing SSYs and closed in E^ then E' is 
called the signature generated in E by SSYs and is denoted by 

Proposition 4.4 (CASL-specific). The following are equivalent for a sub- 
signature E of E' : 

1. E is a full subsignature of E' . 

2. E inherits the subsort relation from E' (i.e. < = <' n{S x S)) and to- 
tality of function symbols (i.e. a function symbol of E that is total in E' 
must already be total in E - formally this means PF^s C TF'^^ = 0 for 
each ws ^ S* X S). 

Proof. (1) ^ (2): Let E = {S^TF^PF^P^<) be a full subsignature of E' = 
{S', TF', PF', P', <'). Then E" = {S, TF", PF", P, <") with 

• <" = <'0(5x5')), 

. TF",= 

• PP", = pp'„, n ( TF^s u PF^s) 

is a subsignature of E' with |i7| = \E"\. By fullness, E" C E, hence, <'n(5 x 
5) C < (while the converse inclusion holds since E C E'). Moreover, by E" C 
i7, PF'(^^ = PF'^^ D{TFws U PFws)^ T PFws, which implies TF^s H PF'^^ = 0 
(note that and PFy^s are disjoint). 

(2) ^ (1): Let E = {S,TF, PF, P, <' n (5 x 5)) be a subsignature of E' = 
(5', TF', PF', P', <'). Given any subsignature E" = {S",TF", PF", P", <") 
of E' with \E\ = \E"\, E and E" can differ only in the subsort relation and in 
totality of function symbols. Since <" C <' by the subsignature property, and 
5 = 5" by |P| = \E"\, we have <" C <' n (5 x 5). Moreover, if / G TF'(^^, by 
the subsignature property, also / G TF'^^. Since TF y^s^PF ws = 

TFyjs n PFyjs = 0 and moreover, PFyjs H TF'^^ = 0 by assumption, we get 
/ G TFyjs. Thus, E" CP. □ 

Proposition 4.5 (CASL-specific). For any set SSYs C \E\, exists. 

Proof Let P = (5, PP, PP, P, <). Given SSYs C |P|, let SSYs' be the union 
of SSYs with all the sort symbols occurring in prohles of signature symbols 
in SSYs. Obviously, SSYs' is the smallest set containing SSYs and closed in 
P. Let Pl^^vs = (5',PP',PP',P',<) n {S' X S')) where 

S' = {s e S \ s e SSYs'}, 

TF'^^ = {/ G TFy^s I Us G 55T5'}, 

PP;, = {/ G PF^s I Us G 55T5'}, 

P'{w) = {pe P{w) I Py, G SSYs'}. 
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By Prop. 4.4, r|ssys is a full subsignature of U with set of signature sym- 
bols SSYs' . Clearly, E\ ssYs is unique with this property. Together with the 
property that SSYs' is the smallest set containing SSYs and closed in this 
gives the desired result. □ 



A set of signature symbols SSYs in \Y\ also determines the inclusion of 
the largest subsignature q£ does not contain any of these 

signature symbols. (When a sort is not included, no operation or predicate 
symbol with that sort in its prohle can be included either.) 



Given a set SSYs C |A|, if there is a unique full subsignature Y' of Y 
such that \Y'\ is the largest set disjoint from SSYs and closed in A, then Y' 
is called the signature eo- generated in Y by SSYs and is denoted by 

Proposition 4.6 (CASL-specific). For any set SSYs C \Y\, exists. 

Proof. Analogous to the proof of Prop. 4.5. □ 



A mapping r of symbols in \ \Y\ \ determines the morphism r\^ from Y that 
extends this mapping with identity maps for all the remaining names in | |T| |. 
In case such a signature morphism does not exist, the enclosing construct is 
ill- formed. 



Given a signature Y and a symbol map r C Sym x Sym^ a generating 
signature morphism a: Y ^ Y' matching r and leaving names unchanged 
outside r is called the signature morphism from Y indueed by r, provided that 
a is unique with these properties. If it exists, we will denote it by r\^ . 

Given signatures Y and A', a mapping r of symbols in \\Y\\ to symbols in 
1 1 A' 1 1 determines the unique signature morphism r|^, from Y to Y' that 
extends the given mapping, and then is the identity, as far as possible, on 
common names of Y and Yh (Mapping an operation or predicate symbol 
implies mapping the sorts in the prohle consistently.) In case such a signature 
morphism does not exist or is not unique, the enclosing construct is ill- 
formed. 



Let signatures Y and Y' and a symbol map r C Sym x Sym be given. 
Now r determines the set of all signature morphisms a: Y^ Y' such that 
there is some set SSYs of signature symbols with 

1. a matches r and leaves names unchanged on SSYs (where the latter means 
that name{\a\{SSY)) = name{SSY) for each SSY G SSYs), and 

2. SSYs is maximal with the property that for some signature morphism 0 : 
Y ^ Y' ^ 6 matches r and leaves names unchanged on SSYs (the maxi- 
mality here implements the ‘as far as possible’ requirement on page 35 of 
the Summary). 
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If this set is a singleton, its unique element (also called r|^,) is the signature 
morphism from U to U' indueed by r. 

When a generic specihcation (given by the inclusion A : U ^ U' of its for- 
mal parameters into the body) is instantiated, the htting arguments yield 
a signature morphism a: U ^ which is then extended to a signature 
morphism cr(Z\) : E' U Ea{A) that is applicable to the signature E' of 

the body of the generic specihcation. The resulting signature Ea U Ea{A) 
is the union of the htting arguments with the translated body. 

An instantiation of a generic specihcation is not well-formed if the result 
signature is not a pushout of the body and argument signatures. 



At the level of symbols, the construction is basically a set-theoretic union, 
where some side conditions ensure that this gives a set-theoretic pushout. 
Since we use hnal signature morphisms and hnal unions to lift this to the 
level of signatures, and hnal lifts of colimits are again colimits, we can show 
that the construction, if dehned, always yields a pushout. 

Given a signature extension A: E ^ E' and a signature morphism a: E ^ 

if: 

• the signature morphism from E' induced by 

r = Ext{\\a\\) n (||r'|| X Sym) 

exists^ (let its target be denoted by Ea{A)); 

• the union Ea U Ea{A) exists, and moreover, is hnal^; 

• |A^|n|A^(zl)| C |a|(|A|) and 

• ker{\{r\^ )|) C ker{\a\) 

then ijjy^(A)cuAUUAA) is called the extension of a along Z\, denoted by 

a(Z\): A'^AaUAa(Z^). 

Proposition 4.7. If the extension of a: E ^ Ea along A: E ^ E' exists, 
then 

^ This may fail to exist for several reasons. One is that the symbol map r is not a 
function for reasons that are discussed in footnotes 10 and 11 of Sect. 4.6; another 
is that r is a function, but there is no signature morphism matching it. In Casl, 
the latter can happen for example if r does not preserve the overloading relations. 
An example is given in [38]. 

® The union may fail to be hnal in Casl if symbols newly enter the overloading 
relation, cf. Prop. 4.2. 

^ This property may fail if the actual parameter and the body share symbols that 
are in neither the formal parameter nor the import. 

® This property may fail if the htting morphism a is not injective (say, it maps both 
eleml and elem2 to nat) and this leads to new identihcations in the extension 
(say, both list[eleml] and Ust[elem2] occur in the body, so cr{A) maps both to 
list[nat]), see Sect. 4.6. 
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a(A) 

Ua ^ U Ua{^) 



is a pushout in Sig. 

Proof. The diagram commutes because ||cr|| C r C ||cr(Z\)||. Given any cocone 
{a A • : U' ^U) define 6: \PJa \ U \Ua{^) \ as follows: 

e{sy) = \aA\{sy), if sy G 1^^! 

e{sy) = \a'\{sy'), if sy G \EaA)\, |(r(Zi)|(st/') = sy 

The second line is well-defined because ker{\{r\^ )|) C ker{\a\), and the two 
lines agree on their overlapping part because \Sa\ H |T'^(Z\)| C 1(71(1171) and 
the cocone commutes. 

Clearly, 0 is the unique function from \P^a\ U \Ua{^)\ to \U\ with 0 o 
and (9o |a(Z\)| = |a'|. 

Now 0 o Lz!a(A)ceaUEa(A) o r\^ = a' is a signature morphism. By h- 
nality of r\^ , 6 o ^x’^(/\)cz’auz’a(/^) ^ signature morphism. Since 

^ ° ^Ea^^auEa(A) = is a signature morphism as well, by hnality of the 
union, 0 is also a signature morphism. □ 

4.1.4 Extended Signatures 



Any symbol declared explicitly in the parameter (and not only in the import) 
must be mapped to a symbol declared explicitly in the argument specihcation 
(cf. Sect. 4.3.2 below). 



This requirement eases the use of the default mechanism for symbol maps 
occurring in instantiations of generic specihcations. The reason is that argu- 
ment specihcations are regarded as extensions of the imports. While the latter 
are always instantiated with an identity map, the htting map for the former 
may be computed by the default mechanism. However, in the presence of im- 
ports, in most cases ambiguities will arise, since e.g. the imports as well as the 
actual parameter will declare sorts symbols. By concentrating on the symbols 
declared explicitly in the parameter and the argument specihcation, respec- 
tively, and excluding the symbols from the import, there are fewer potential 
ambiguities. 

However, a prerequisite for realizing this is the ability to distinguish be- 
tween symbols in the argument specihcation that only come from the import 
and those that are explicitly declared or re-declared in the argument specih- 
cation. As mentioned on page 127, when abstracting signature fragments A 
to signature inclusions U ^ A U Z\, information about any re-declaration in 
A of symbols in U is lost. In order to regain this information, we now extend 
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signatures with an additional signature symbol set, called the set of explicitly 
declared signature symbols. 

Technically, we replace the institution with symbols above by a new 
one that can be obtained from the old one in a generic (i.e. institution- 
independent) way. References below to the derived notions from Sect. 4.1.2 
above should be taken to refer to this new institution. 

Category of signatures and signature morphisms: Signatures are pairs 
iSiST), where is a signature from SubSig and SSY C 

\Ijbasic\ 

is a set of signature symbols. Signature morphisms a : 

SSYi) {Eb^^^^,SSY 2 ) are such that a: ^ JJhas^c signature 

morphism from SubSig and laKiSiSTi) C SSY 2 ^ 

Sentences: The sentence functor is just SubSen, acting on the hrst compo- 
nent of signatures. 

Models: The model functor is just SubMod, acting on the hrst component 
of signatures. 

Satisfaction: Satisfaction is just as before. 

Signature symbols: The signature symbol functor is just the signature sym- 
bol functor from before, acting on the hrst component of signatures. 
Symbols: Symbols are dehned as before. 

Signature symbols matching symbols: The matching relation between 
signature symbols and symbols is dehned as before. 

Factorization of signature symbol functor: The factorization of the sig- 
nature symbol functor is dehned as before (the symbol function acting on 
the hrst component of signatures). 

Names of signature symbols: Names of signature symbols are dehned as 
before. 

Empty signature: The empty signature is dehned as before, except that it 
is paired with the empty set of signature symbols. 

Signature unions: Signature unions are dehned component- wise. 
Generating signature morphisms: A signature morphism 

cr: 

is said to be generating if a : ^ is generating in the earlier 

sense, and moreover |cr| : SSY SSY 2 is surjective. 

We additionally dehne the function EmptyExplicit on extended signatures, 
given by 

EmptyExplicit{S’’^’^^^,SSY) = 

4.1.5 Institution Independent Structuring Concepts 

Abusing the notation somewhat, in the rest of the semantics of Casl we will 
work with the institution with fully qualihed symbols dehned in the preceding 
section. The category of extended signatures will be denoted simply by Sig; 




202 III:4 Structured Specification Semantics 

the same notation will be used for the class of its objects, with U used as the 
main met a- variable ranging over it, and a as the main met a- variable ranging 
over signature morphisms. Similarly, the sentence and model functors of this 
institutions will be denoted by Sen and Mod, respectively, with the rest of 
the components of the institution with symbols denoted as they have been so 
far. 

The use of this generic notation is to remind the reader that everywhere 
except for a number of rules concerned with the details of symbol maps in 
Sect. 4.5, no specihc assumptions are made about these concepts, except that 
they form an institution with fully qualihed symbols (satisfying the properties 
listed in Sect. 4.1.1). 

Specification Morphisms 



For a specihcation morphism, it is required that the reduct of each model of 
the target specihcation is a model of the source specihcation; otherwise the 
semantics is undehned. 



Given specihcations SPECi and SPEC 2 with signatures and U 2 and 
model classes Mi and M 2 , respectively, a specification morphism a: SPECi ^ 
SPEC 2 is a signature morphism a: such that M 2 |cr T Mi. 

Generic Specifications 

The static semantics GSs of a generic specihcation is a generic signature 
consisting of two signatures (the import and the body) and a sequence of 
signatures (the formal parameters). (If there is more than one import specih- 
cation, the imports can be united to a single import. This is not possible for 
the parameter specihcations: they have to be instantiated individually.) 

{Ul, {Ui, . . . , Un), ^b) 

or GSs ^ GenSig = Sig x FinSeq{Sig) x Sig 

The requirements on a generic signature GSg = (T’/, (T’l, . . . , T’n), ^s) ^ 
GenSig are: 

• Uj C for 1 < i < n, and 

• i7i U • • • U En T Eb‘ 

Let pairs (T’^, Ci) be given where : Ei^ Ef is a signature morphism, 
for 1 < z < n. We assume that a/ = aiU - • - UanGidBi is dehned, which implies 
by Prop. 4.3 that all the are compatible with each other and compatible 
with the identity id^i- Let A denote the signature extension given by the 
inclusion of i7i U • • • U into T’b. If Ea = E^ U . . . U E;^ is dehned then: 

GSsiiSf, <7i), . . . , an)) = {Sa U Fa{A), af{A)). 



The notations Ea(A) and o-f(A) are dehned on page 199. 
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The model semantics GS^ of a generic specification consists of a model 
class for the import, a sequence of model classes for the formal parameters, 
and a model class for the body of the generic specification. 

{Mi, {Ml,..., Mn'), Mb) 

or GSjn C GenSpec 

Mod (4 Class x Fm6'e^(ModelClass) 

X ModelClass 

A generic signature GSs = (T’j, {Ui, . . . , A^), T’b) C GenSig and an element 
GSm = {Ml, {Ml, . . . , Mn'), Mb) of GenSpec are compatible if 

• n = n' , 

• Mi is a class of Aj-models, 

• each Mi is a class of A^-models and each element of Mi extends some 
model of Mi for 1 < i < n, and 

• Mb is a class of A^-models, each model of which extends some model of 
Mi for each 1 < i < n. 

Let pairs {Mf,ai) be given where Mf is a class of models over Uf and 
ai is a signature morphism from Ui to for 1 < i < n. Provided that 

(r,ap= G5,((ry <71 (rya„)) 

is defined and Mf\a,i C Mi for all 1 < z < n then 

GS,n{{M^, CTi), . . . , {M^, On)) = M 

where M is the class of models over A given by 

M = {M G Mod(A) I M\^a g Mf, 1 < z < n, G Mb}. 



Views 

The static semantics of a view consists of a signature (the source signature), 
a signature morphism, and a generic signature (the target signature of the 
view) . 

or Vs G ViewSig = Sig x SignatureMorphism x GenSig 

For an element {Eg, a, GSg) in ViewSig we require that a is a signature mor- 
phism from Eg to Eb, where GS s = {Ei, {Ei, . . . , En), Eb). 

The model semantics of a view consists of a model class and the model 
semantics of a generic specification. 

{Mg, GS^) 

or Vm ^ ViewSpec = ModelClass x GenSpec 

An element Vg = {Eg, cr, GSg) in ViewSig and an element V^ = {Mg, GSm) 
in ViewSpec are compatible if 
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• A4s is a class of i^s-models, 

• = (i7/, (i7i, . . . , Un). ^b) and GSm = {Mi, {Mi, . . . , Mnj^Ms) are 
compatible, and 

• Msla^Ms. 

Local and Global Environment 



Within a structured specification, the current signature, also called the local 
environment, may vary. The current association between names and the 
specihcations that they reference is called the global environment. 

As introduced elsewhere (cf. Sect. 6.1), model (resp., static) global en- 
vironments Fjn (resp., Fg) contain a generic specihcation component Qm : 

SpecName ^ GenSpec (resp. Qg : SpecName ^ GenSig), as well as a 

view component Vm • ViewName ^ View'Spec (resp. Vg : ViewName ^ 
ViewSig). 

A static global environment and a model global environment are compatible 
if their components are compatible, see Sect. 6.1. Compatibility for the generic 
specihcation and view components has been dehned above. 

The rest of this chapter indicates the semantics of the constructs of struc- 
tured specihcations. 



4.2 Structured Specifications 

The static semantics of a specihcation has been given as a signature extension 
A of the local environment F in Chap. 2, where signature extension referred 
to a signature fragment. At the institution independent level, where we do 
not have signature fragments, this is abstracted to the signature inclusion 
A ^ AUZ\. As mentioned on page 127, information about any re-declaration 
in A of symbols in F is lost by this abstraction. Therefore, in Sect. 4.1.4 we 
provide a mechanism that keeps the symbols of A together with F U A. 

In structured specihcations, a specihcation SPEC may occur in a context 
where it is to extend other specihcations, providing itself only part of a 
signature. Hence, its interpretation determines an extended signature F' , 
given a signature F (the local environment), together with a model class 
over F' (when dehned), given a model class over F. 

Translations and reductions in a SPEC are not allowed to affect symbols that 
are already in the local environment that is being extended. 



SPEC ::= BASIC-SPEC I TRANSLATION | REDUCTION 

I UNION I EXTENSION | FREE-SPEC I LOCAL-SPEC 
I CLOSED-SPEC 

GASL-specific rules for basic specifications 
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i:, Fs h SPEC > i:' i:, m, a, h spec ^ m' 



Fs and F^ are compatible global environments and Ad is a class of models 
over then F' is an extension of and Ad' is a class of models over F' 
with each model extending some model in Ad. Recall that signatures F are 
pairs with SSY C 

jjhasic g basic-spec > (A, F) 

(^Fbasic^ SSY), Fs h BASIC-SPEC qua SPEC > y ^SY U \ A\) 

F,Mh BASIC-SPEC ^ Ad' 
i:, Ad, Fs, Fm BASIC-SPEC qua SPEC ^ Ad' 



end of CASL-specific rules 
Other rules elided (see Sect. 1.3). 



4.2.1 Translations 



The symbols mapped by SYMB-MAP-ITEMS+ must be among those declared by 
SPEC. The signature F given by SPEC and the mapping SYMB-MAP-ITEMS+ 
then determine a signature morphism to a signature i7', as explained in 
Sect. 4.1, which must not affect the symbols already declared in the local 
environment. The class of models of the translation consists exactly of those 
models over F' whose reducts along the morphism are models of SPEC. 



TRANSLATION ::= translation SPEC RENAMING 
RENAMING ::= renaming SYMB-MAP-ITEMS+ 

i: h RENAMING F^F' 

is a signature; then a : F ^ F' is a hnal signature morphism. 

h SYMB-MAP-ITEMS+ > r 
i: h renaming SYMB-MAP-ITEMS+ > r|^ 

i:, Fs h TRANSLATION > F' F, Ad, A, Fm ^ TRANSLATION ^ Ad' 



Fs and Fm are compatible global environments, and Ad is a class of models 
over F; then F^ is an extension of F and Ad' is a class of models over F^ with 
each model extending some model in Ad. 
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i:, Fs h SPEC > i:' 
i:' h RENAMING \> a : 

I (7 1 is the identity on signature symbols in |i7| 
i:, Fs h translation SPEC RENAMING > E" 

Note that E C E" because |cr| is the identity on signature symbols in \E\. 

E, Fs h SPEC > E' 

E' h RENAMING \> a : E'^E" 

E ^ M, -Tg, Fjyi h SPEC ^ A4' 

E,M,Fs,Fjn^ translation SPEC RENAMING ^ 

{M G Mod(i:") I M\^e M'} 



4.2.2 Reductions 

In the case of a hiding reduction, the signature E given by SPEC and the 
set of symbols listed by SYMB-ITEMS+ determine the inclusion of the largest 
subsignature E' of E that does not contain any of the listed symbols, as 
explained in Sect. 4.1. 

In the case of a revealing reduction, the signature E given by SPEC and the 
set of symbols mapped by SYMB-MAP-ITEMS+ determine the inclusion of the 
smallest subsignature E' of E that contains all of the listed symbols, as 
explained in Sect. 4.1. This signature then may be further translated. 

A reduction must not affect the symbols already declared in the local envi- 
ronment. 



REDUCTION 

RESTRICTION 

HIDDEN 

REVEALED 



reduction SPEC RESTRICTION 
HIDDEN I REVEALED 
hidden SYMB-ITEMS+ 
revealed SYMB-MAP-ITEMS+ 



(A, E') h RESTRICTION >a: Ei^E" 

E' is an extension of A; then E F E\ F E' ^ and |cr| is the identity on signature 
symbols in \E\. 



I A'l h SYMB-ITEMS+ > SSYs 
S'S'Tsn |A| = 0 Ei = 

(A, E') h hidden SYMB-ITEMS+ > 

The second premise ensures that no symbols from E are hidden. 

h SYMB-MAP-ITEMS+ > r 

SSYs = {SY G |A'| I SSY matches some SY G dom{r)} 
El = a: Ei^E" = 

I (7 1 is the identity on signature symbols in |A| 

(A, E') h revealed SYMB-MAP-ITEMS+ Ei^E" 
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The third premise generates all symbols from the symbol map and also the 
symbols from the local environment into the revealed signature. The hfth 
premise ensures that the local environment is not renamed. Note that E Ei. 



E, Fs h REDUCTION > i:' i:, M, A, F^ h REDUCTION ^ M' 



Fs and are compatible global environments and Ad is a class of models 
over E; then E' is an extension of E^ and A4' is a class of models over E' 
with each model extending some model in Ad. 

i:, Fs h SPEC > i:' 

(E, E') h RESTRICTION >a: Ei^E" 

E, Fs h reduction SPEC RESTRICTION > E" 

Note that E C E" because E C Ei and \a\ is the identity on signature 
symbols in \E\. 



E, Fs h SPEC > i:' 

(E, E') h RESTRICTION Ei^E" 

E ^ Ad, iA, Fjyi h SPEC ^ Ad^ 

E,M,Fs,Fjn^ reduction SPEC RESTRICTION ^ 

{M" G Mod(i7") I there is some M' G Ad' with = Tf"|cr} 



4.2.3 Unions 



The signature of the union is the union of the signatures of each SPEC. Thus 
all occurrences of a symbol in the SPECs are interpreted uniformly. The 
models are those models of the union signature for which the reduct to the 
signature of the SPEC is a model of that SPEC. 



UNION : := union SPEC+ 



i:, Fs h UNION > i:' i:, Ad, a, h union ^ m' 

Fs and F^ are compatible global environments and Ad is a class of models 
over E; then E' is an extension of E^ and Ad' is a class of models over E' 
with each model extending some model in Ad. 

i:, Fs h SPECi > El 
E, Fs h SPECn > En 



E, Fs h union SPECi . . . SPEC^ > EiU . . .U E^ 




208 III:4 Structured Specification Semantics 



r, Fs h SPECi > El 

E, Fs h SPEC„ > En 
E, M, Fs, Fm SPECi ^ Ml 

U,M,rs,rm^SPECn^ Mn 

i:, A, h union SPECi . . . SPEC^ ^ 

{M G Mod(i7i U . . . U Un) I M\jj. G A4i, 1 < i < n} 



4.2.4 Extensions 



SPECi determines an extension from the local environment to a signature 
Ui. For i = 2,...,n each SPEC^ determines an extension from i7^_i to a 
signature Ui. The signature determined by the entire extension is then 
Models are determined similarly, with each SPEC^ determining a class A4i of 
i7^-models whose i7^_i-reducts are in A4i-i. 



EXTENSION ::= extension SPEC+ 



i:, Fs h EXTENSION > M, A, h EXTENSION ^ M' 



Fg and are compatible global environments and At is a class of models 
over F; then F' is an extension of F^ and At' is a class of models over F' 
with each model extending some model in At. 

i:, Fg h SPECi > Fi 

Fn-l,Fg h SPECn > Fn 
F, Fg h extension SPECi . . . SPEC^^ > F^ 

F, Fg h SPECi > Fi 

A'n— i,Tg \~ SPECtt, I> Ffi 
F, At, Fg, Fm F SPECi ^ Ati 

A’n— 1 5 At7T,_i , Tg , /A SPECtt, => Fifi 
F,A4, Fg, Fm F extension SPECi . . . SPEC^ ^ Ain 

A semantic annotation can occur at any point in the list of extensions and 
then concerns only the extension at that point. If the annotation is attached 
to the i — extension (i.e. between SPEC^_i and SPEC^, where 2 < i < n)), 
then it holds under the following conditions. 
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• %cons {conservative): each model M G A4i-i has an A4i~ extension^ i.e. a 

model M' G A4i such that = M. 

• %mono {monomorphic): each model M G A4i-i has a unique A4i~ 
extension up to isomorphism, i.e. any two Ad^-extensions are isomorphic. 

• %def {definitional): each model in A4i-i has a unique Ad^-extension 

• %implies {implicational): Ei = Ei-i and A4i = Ad^-i- 

4.2.5 Free Specifications 

SPEC determines an extension from the local environment to a signature E' . 
free- spec SPEC determines the class of i7'-models that are free extensions 
for SPEC of their own reducts to models of the current local environment. 



FREE-SPEC : := free-spec SPEC 



i:, Es h FREE-SPEC > At, A, h FREE-SPEC ^ M' 

Eg and Ej^ are compatible global environments and At is a class of models 
over E; then E' is an extension of E^ and At' is a class of models over E' 
with each model extending some model in At. 

E,Eg h SPEC > E' 

E, Eg h free-spec SPEC > 

i:. At, Eg, Em h SPEC ^ Ati 
i:. At, Eg, Em ^ free-spec SPEC ^ 

{M G Ati I M is a free extension of w.r.t. Ati} 

A model M is a free extension of w.r.t. a class of models Ati if for all 
elements Mi of Ati and homomorphisms h : M\jj ^ Mi\jj there exists a 
unique homomorphism : M Mi with h^\jj = h. 

If E is the empty local environment 0 then M |0 is the only element of 
Mod(0) and for each Mi in Ati the identity id on M\jj is a homomorphism 
from Mix’ to Mi|x- If M is a free extension of M |0 w.r.t. Ati then id extends 
to a unique homomorphism id^ from M to Mi, which makes M an initial 
object of Ati. 

In the Casl institution, under some minor restrictions the basic specihcation 
written: 

free types DDi; . . . DD^; 

has the same interpretation as the free structured specihcation written: 
free { types DDi; . . . DD^ } 
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See Theorem 3.11 in Sect. 3.2.2 for an equivalence between free types as 
Casl basic specifications and structured free datatypes, and for details of 
what the minor restrictions are. 



4.2.6 Local Specifications 



Declaring SPECi as local to SPEC 2 is equivalent to an extension of SPECi by 
SPEC 2 , followed by a hiding of all the symbols declared by SPECi that are 
not already in the current local environment. 



LOCAL-SPEC ::= local-spec SPEC SPEC 



i:, Fs h LOCAL-SPEC > M, A, h LOCAL-SPEC ^ M' 



Fs and are compatible global environments and At is a class of models 
over F; then F' is an extension of F^ and At' is a class of models over F' 
with each model extending some model in At. 

i:, Fs h SPECi > i:' i:', h spec2 > f" 

|V'| \ |V| c l^il 

F^Fs h local-spec SPECi SPEC 2 > Fi 

The last premise ensures that symbols newly introduced in SPEC 2 are not 
hidden. 



i:, Fs h SPECi > i:' F', Fs h SPEC2 > F'' 

Fi = F"\\^'\W^\ 

F, At, Fs, Fm h SPECi ^ At' i:'. At', A, Fm h SPEC2 ^ At" 
i:. At, Fs,Fm h local-spec SPECi SPEC2 ^ \ M G At"} 

4.2.7 Closed Specifications 

A closed specihcation determines the same signature and class of models as 
SPEC determines in the empty local environment. 



CLOSED-SPEC : := closed- spec SPEC 



A, Fs h CLOSED-SPEC > A' A, At, A, F^ h CLOSED-SPEC ^ At' 
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Fg and Fj^ are compatible global environments and Ad is a class of models 
over F; then is an extension of F^ and Ad' is a class of models over F^ 
with each model extending some model in Ad. 

0,T5 h SPEO i:' 

F, Fg h closed-spec SPEC \> F U F' 

(i,Fg h SPEO i:' 

0, Mjl, a, h SPEC ^ M' 

M" = {M e Mod(i: u V) I m\e e M, m\e' e M'} 

F, Ad, Fg^Fjn h closed-spec SPEC ^ Ad" 

The union F VJ F' and the construction of Ad" ensure the invariant that 
the resulting signature extends the local environment signature F^ and that 
each resulting model extends one from Ad. 



4.3 Named and Generic Specifications 

4.3.1 Specification Definitions 



A generic specihcation dehnition dehnes the name SN to refer to the 
specihcation that has parameter and import specihcations as indicated by 
GENERIC ITY, and body specihcation SPEC. This extends the global environ- 
ment (which must not already include a dehnition for SN). 

The declared parameters show just which parts of the generic specihcation 
are intended to vary between different references to it. The imports, in con- 
trast, are hxed, and common to the parameters, body, and arguments. 



SPEC-DEFN 

GENERICITY 

PARAMS 

IMPORTED 

SPEC-NAME 



= spec-defn SPEC-NAME GENERICITY SPEC 
= genericity PARAMS IMPORTED 
= params SPEC* 

= imported SPEC* 

= SIMPLE- ID 



Though possible in the abstract syntax, the concrete syntax does not allow 
an import to be specihed for non-generic specihcations. Thus, if the import is 
not empty for a non-generic specihcations, the static semantics will be unde- 
hned. This is captured in the rule for GENERICITY below. As a consequence, the 
static semantics of a non-generic specihcation is always of the form (0, (), 
and the model semantics is of the form {A4±, (), Ad^) where Ad^ is a class of 
A^-models. 



Fg h SPEC-DEFN > F' Fg.F^^ SPEC-DEFN ^ F^ 
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Fg and Fj^ are compatible global environments; then F^ and F;^ are compatible 
environments extending Fg and F^^ respectively. 

Cs = {Qs,Vs,-As,Ts) 

SN ^ Dom{Qs) U Dom{Vs) U Dom{As) U Dom(Ts) 

Fs h GENERICITY t> {Sj, {Fi,..., r„)) 

u • ■ • u r„, r, h SPEC > Eb 

Fs h spec-defn SN GENERICITY SPEC > 

{g, U {SN ^ {Ei, (^i, . . . , En), Eb)}, .4,, %) 



-Cn — {gray^myAray^m) 

Fg h GENERICITY t> (Ej, {Ei,..., E„)) 

Fs,Fm h GENERICITY ^ (Mi, {Mi, . . . , M„}} 

Ml p = {M G ]VIoci(i7i U . . . U Eji) I M\bj g Mil, M\b^ G Mli, 1 ^ i ^ n{ 
EiU---U E„,Mp, Fg, Fm I- SPEC ^ Mb 
Cs, h spec-defn SN GENERICITY SPEC ^ 

ig,n U [SN ^ (Ml, {Ml,..., M„),Mb)}, Vm,A,n, %n) 



Fg h GENERICITY t> (Ej, (^i, . . . , i7„)) 

Fs,Fm h GENERICITY^ (Mi, {Mi, . . . , M„}) 



Fs and F^n are compatible global environments; then Mi is a class of models 
over Ei, Ei is an extension of Ei and Mi is a class of models over Ei with 
each model extending some model in AIj for 1 < i < n. 

Fs b IMPORTS t> Ei 
E i,Fs^ PARAMS > {Ei,...,En) 
n > 1 

Fs b genericity PARAMS IMPORTS t> (Ep {Ei,..., En)) 



Fs b IMPORTS t> Ei 
r«, b IMPORTS ^ Ml 
Ei,Mi,Fs,Fm b PARAMS^ {Mi,...,Mn) 

Fs,Fm b genericity PARAMS IMPORTS ^ (Mi, {Mi,...,M„}) 

In case there are no parameters, the import should be empty. If not, the 
semantics of GENERICITY is undefined: 

Fs b IMPORTS > 0 
0, r« b PARAMS > 0 

Fs b genericity PARAMS IMPORTS > (0, ()) 
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hPARAMS^ 0 

A, Pm genericity PARAMS IMPORTS ^ ()) 



i:, Fs h PARAMS > {Fi,...,Fn) 

E,M,rs,Fm h PARAMS^ (Mu...,Mn) 



Fg and Fj^ are compatible global environments and Ad is a class of models 
over F; then Fi is an extension of F and Aii is a class of models over Fi with 
each model extending some model in Ad for 1 < i < n. 

F, Fg h SPECi > Fi 

F, Fg h SPECn > Fn 

F, Fg h params SPECi . . . SPEC^ > {Fi,...,Fn) 

F,M, Fg, Fm K SPECi ^ Adi 



F, Ad, Fg, Fm ^ SPECn ^ Mn 
F,M, Fg, Fm ^ params SPECi . . . SPEC^ ^ (Adi, . . . , Ad^) 



Fg h IMPORTS > i: Fg,Fm^ IMPORTS ^ Ad 

Fg and Fm are compatible global environments; then Ad is a class of models 
over F. 

If the list of imported specihcations is empty then the semantics of the 
import construct is the empty signature 0 with Ad^ as its class of models. 



Fg h imports > 0 



Fm imports ^ Ad^ 

For a non-empty list of imported specihcations, the semantics of 



imports SPECi . . . SPEC^ 

is the same as union SPECi . . . SPEC^^ with respect to the empty local environ- 
ment. 

0, Fg h union SPECi . . . SPEC^ > X’ 

Fg h imports SPECi . . . SPEC^ > Empty Explicit {F) 

For the dehnition of Empty Explicit , see Sect. 4.1.4. 

0, Ad±, Fg,Fm^ union SPECi . . . SPEC^ ^ Ad 
Fm F imports SPECi . . . SPEC^ ^ Ad 
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4.3.2 Specification Instantiation 



An instantiation SPEC- INST of a generic specification with some fitting ar- 
gument refers to the specihcation named SN in the global environment, 
providing a htting argument FIT-ARG^ for each declared parameter (in the 
same order). 

When there is more than one parameter, the separate htting argument mor- 
phisms have to be compatible^ and their union has to yield a single morphism 
from the union of the parameters to the union of the arguments. 

Each model of a htting argument, when reduced by the signature morphism 
for that htting argument, is required to be a model of the corresponding 
parameter specihcation, otherwise the instantiation is undehned. 



SPEC ::= ... I SPEC- INST 

SPEC-INST ::= spec-inst SPEC-NAME FIT-ARG* 

FIT-ARG ::= FIT-SPEC 

FIT-SPEC ::= fit-spec SPEC SYMB-MAP-ITEMS* 



A, Fs h SPEC-INST > A' A, M, A, h SPEC-INST ^ M' 



Fs and Fm are compatible global environments and Ad is a class of models 
over F; then F' is an extension of F and A4' is a class of models over F' with 
each model extending some model in A4. 

First, we study the case where the specihcation name refers to a non- 
generic specihcation with static semantics ( 0 ,(),A 5 ) and model semantics 

(Ad±, 0, Ads)- 

-Ts = {Qs'j^S'j '^S'j'^s) 

gs{SN) = {^,{),FB)) 

A, Fs h spec-inst SN \> F U Fb 



A = (0s, Vs, 

0s(^Ar) = (0,(),AB) 

~ (0m, Vttt,, AIttt,, ^7^) 

0^(^A) = (Ad^,(),AdB)) 



A,Ad,Es,7Vi ^ spec-inst SN ^ 

{M G Mod(A U Fb) \ M|^ G Ad, M\e^ ^ Mb} 



Now the generic case, i.e., the a generic specihcation with static seman- 
tics (A/, (Ai, . . . , Fn), Fb) and model semantics (Ad/, (Adi, . . . , Mti),Mb), 
where n > 1. 
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-Ts = (Qs,Vs,As,Ts) 

GsiSN) = GSs = n>l 

Si, Si,rs\- FIT-ARGi \>ai,S^ 

Si, Sn, r, h FIT-ARG„ t> an, S^ 

{S' ,af) = GSs{{S^,ai), ..., (S:^,an)) is defined® 

S, Sg h spec-inst SN FIT-ARGi . . . FIT-ARG„ t> S \J S' 



r.s = {g.s,Vs,As,%) 

g,{SN) = GSs = {Si,{Si,...,Sn),SB), n>l 
Si,Si,Ts FIT-ARGi \>ai,S^ 



Si, Sn, Fs h FIT-ARG„ > a„, S^ 
{S',af)= GSs{{S^,ai),...,{S^, an)) is defined 

Fjn — {Qm,Fni, Ajn,Fm) 

g„^{SN) = GSm = {Ml,(Mi, . . . ,Mn),MB) 
Si,Si,Mi,Mi,rs,rm hFIT-ARGi ^ Mf 



Si, Sn, Mi, M„, T,, Fm h FIT-ARG„ ^ 

S, M, Fs, Fm I- spec-inst SN FIT-ARGi . . . FIT-ARG„ ^ 

{M e Mod(r U S') I M\s e M, M\b' e GSm{{Mt, ^i), ■■■, (M^, an))} 



For a fitting argument specification, the signature Ua given by its argument 
specification, the signature Up given by the corresponding parameter spec- 
ihcation, and the symbol mapping SYMB-MAP-ITEMS+ determine a signature 
morphism from Up to Ua^ as explained in Sect. 4.1.5. 



Ui, Up, Us h FIT-ARG > a, 

Up Up, Mi, Mp, Us, Fm F FIT-ARG ^ Ma 



Fg and are compatible global environments. Up is an extension of Up 
Mi a class of models over Ui and Ad p is a class of models over Up with each 
model extending some model in Mi; then Ua is an extension of i7/, a is a 
signature morphism from Up to Ua which is the identity when restricted to 
Ui, and Ma is a class of models over Ua^ Furthermore, the a-reduct of each 
model in Ma is a model of Mp. 

(Up,Mp) is one formal parameter of a generic specihcation. (Ua^Ma) 
is the corresponding actual parameter and a is the htting morphism between 
formal and actual parameter. 

See Sect. 4.1.5 for an explanation of the notation GSs{. • •)• 



9 
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Rules elided, including the case of FIT-VIEW added in Sect. 4.4.2 below. 



Ui, Up, Fs h FIT-SPEC > a, 

Up Up, Ml, Mp,rs,Tm^ FIT-SPEC ^ Ma 



Fg and Fj^ are compatible global environments, Up is an extension of Uj, 
Mi a class of models over Uj and Ad p is a class of models over Up with each 
model extending some model in Mj; then Ua is an extension of i7/, a is a 
signature morphism from Up to Ua which is the identity when restricted to 
Uj, and Ma is a class of models over Ua^ Furthermore, the a-reduct of each 
model in Ma is a model of Mp. 

UpFs h SPEO 
h SYMB-MAP- ITEMS* > r 
a=(rU{(5r,gr)|5Fe||j7j||})|g^ 

Si, Sp, Fg h fit-spec SPEC SYMB-MAP- ITEMS* t> a, Sa 

See Sect. 4.1.3 for the definition of :Sp^Sa, the signature morphism 
induced by the symbol map r. 

T/, P h SPEC > Sa 
h SYMB-MAP- ITEMS* > r 

a=(rU{(5r,5r)|5Fe||i7/||})|i- 
Up Mp Fg,F^h SPEC ^ Ma 

MaVFMp 

UpUp,MpMp,Fs,Fm h fit-spec SPEC SYMB-MAP- ITEMS* ^ Ma 



4.4 Views 

4.4.1 View Definitions 



A view dehnition declares the view name VN to have the type of spec- 
ihcation morphisms from SPECi to SPEC 2 , parameter and import specih- 
cations as given by GENERICITY, and dehnes it by the symbol mapping 
SYMB-MAP- ITEMS+. 

SPECi gets the empty local environment. The well-formedness conditions for 
SPEC 2 are as if SPEC 2 were the body of a generic specihcation with formal 
parameter and import specihcations as given by GENERICITY. 

It is required that the reduct by the specihcation morphism of each model 
of the target is a model of the source; otherwise the semantics is undehned. 
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VIEW-DEFN ::= view-defn VIEW-NAME GENERICITY VIEW-TYPE SYMB-MAP-ITEMS* 
VIEW-TYPE : : = view-type SPEC SPEC 
VIEW-NAME ::= SIMPLE-ID 



Fs h VIEW-DEFN > A, h VIEW-DEFN ^ 

Fg and Fm are compatible global environments; then F^ and F^ are compatible 
environments extending Fg and Fm, respectively. 

= (^Qs,'^s, -A-SjTs) 

VN ^ Dom{Vs) U Dom{Qs) U Dom{As) U Dom{Ts) 

Fg h GENERICITY t> {Ei, {Si,..., S„)) 

SiU---USn,Fg\~ VIEW-TYPE > {Sg, St) 
h SYMB-MAP-ITEMS* t> r a = r|f J 
Fg h view-defn VN GENERICITY VIEW-TYPE SYMB-MAP-ITEMS* > 

{Gg, VgV{VN^ {Sg, a, {Si, {Si,..., S^), St))],Ag,Tg) 

See Sect. 4.1.3 for the definition of r\^{ :Sg^St, the signature morphism in- 
duced by the symbol map r. 



Fg h GENERICITY t> {Si, {Si,..., Sn)) 

Si\J---\JSn,FgV- VIEW-TYPE > {Sg, St) 

\- SYMB-MAP-ITEMS* > r (j = 

Fg,Fm I- GENERICITY ^ {Mi, {Mi, . . . , M„)) 

M.p = {M G Mod(dl'p) I G Nil, G At*, 1 < i < n\ 

Si U---USn,Mp,Fg,Fm b VIEW-TYPE^ {Mg,Mt) 

Mt\a C Mg 

Fg,Fm I- view-defn VN GENERICITY VIEW-TYPE SYMB-MAP-ITEMS* ^ 

{Qm, VmU{VN^ {Mg, {Mi, {Ml,..., Mn),Mt))}, Am,%n) 



S, Fg VIEW-TYPE > {Sg, St) S, M, Fg, Fm b VIEW-TYPE ^ {Mg, Mt) 

Fg and Fm are compatible global environments and At is a class of models 
over S; then St is an extension of S, Mt is a class of models over St with 
each model extending some model of M, and Ads is a class of models over 

0, Fg b SPECi t> Ts 
r, Fg b SPEC2 > St 

S, Fg b view-type SPECi SPEC 2 l> {Sg, St) 

%,Mp,Fg,Fm b SPECi ^ Mg 
S, M, Fg, Fm b SPEC 2 ^ Mt 



S,M,Fg,Fm b view-type SPECi SPEC 2 => {Mg,Mt) 




218 III:4 Structured Specification Semantics 

4.4.2 Fitting Views 

A reference to a fitting argument view refers to the current global environ- 
ment, and is well- formed as an argument for a parameter SPEC^ only when 
the global environment includes a (possibly generic) view dehnition for VN 
(possibly with parameters that can be instantiated by the indicated htting 
arguments FIT-ARG+) to give a view of type from SPEC to SPEC', such that 
the signatures of SPEC and of SPEC^ are the same. The view dehnition then 
provides the htting morphism from the parameter SPEC^ to the argument 
specihcation given by the target SPEC' of the view. 

Each model of SPEC is required to be a model of SPEC^, otherwise the instan- 
tiation is undehned. The instantiation of a generic view with some htting 
arguments is not well-formed if the instantiation of the target SPEC' of the 
view with the same htting arguments is not well- formed. 



FIT-ARG ::= ... I FIT-VIEW 

FIT-VIEW ::= fit-view VIEW-NAME FIT-ARG* 



A/, Up, Fs h FIT-VIEW > a, 

FpFp.MpMp.Fs.rm K FIT-VIEW^ A4a 

Fg and are compatible global environments. Up is an extension of Up 
A4j a class of models over Fj and A4p is a class of models over Fp with each 
model extending some model in Mj; then Fa is an extension of A/, a is a 
signature morphism from Ap to Fa which is the identity when restricted to 
Fj, and A4a is a class of models over Furthermore, the a-reduct of each 
model in A4a is a model of A4p. 

First we study the situation where VN denotes a non-generic view. 

— (Qs J J Vlg j 

Vg(VN) = (Fg,a, (0,0, Ft))) 

Fg U F/ = Fp 

Fp Fp^ Fg h fit-view VN > a U Fj U Ft 

Here, Fj is the import signature, Ap is the parameter signature, which is 
the source of the view, and Fa is the argument signature, which is the target 
of the view. 



i:. ^ 



Fj^ ^ Fg U Fi 



Fi U Ft 



aUidjjj 
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-Ts — {Gsi^Sl 

V,(V7V) = (V„a, (0,0, i^t))) 

Vm{VN) = {Ms,{M^,{),Mt)) 

{M G Mod(Vp) I M\jj^ G Ms, M\jj, G Mi} C Mp 
Up Up^ Mp Mp, Fs,rjn ^ fit -view VN ^ 

{M G Mod(Vj U Ut) I G Mp M\e^ g Ait} 



Note that MA\avjid^^ F Mp follows from MA\auid^^ F Mg and Ai^ C 
Mp, where M^ = {M G Mod(Vp) | G Ms, M|^/g Mjj. 

To show that MA\cr\jid^^ T M'g holds, consider M G Ai^- We have to 
show that M\^uid^^ ^ M'g, that is, {M\^uid^^)\us ^ and {M\^uid^^)\ui ^ 
Mp The following equality holds by the dehnition of a U idp^: 



a U idpj o LpjCSiUEs = ^UiCSiUEt 



Then we have: 



{M\crUid^j)\Es = (Af|z’t)|cr ^ Ms 

since M ^ Ma implies M\ Mt by the dehnition of Ma and because 
Mt\a T Ms by the properties of view morphisms. 

Further, the following equality holds by the above diagram: 

^Z’tCZ’/UZ’t o (7 = (7 U idpj o Lp^CPiUUs 



This implies 



{M\aUid^j)\Ei = G Ml 

since M ^ Ma implies M\pj G Mi by the dehnition of Ai^- 
Now we come to the generic case: 

Fs = {Gs,Fs, >A.s,Fs) 

Vs{VN) = {Us,a, GSs)) 

Us U Ui = Up 

GSs = {U'j,{Up...,Un),UB), n>l 
U},Ui, Fsh FIT-ARGi >ai,U^ 

S'j, r„, r, h FIT-ARG„ t> ( 7 „, 

(Sa,A) = GSs{{Sl,ai), p^,an)) is defined 
EiApPs h fit-view VN FIT-ARGi . . ,FIT-ARG„ t> 

((7j o a) U idpj , Ui U Ua 
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I 






r/ 






a 



Sb 



a 



f 



n 






Us u Sj 



(a'fOa)Uidsr ' 

^ U Si 



Sp 



A = {Gs,Vs,As,%) 

Vs{VN) = {Ss,a, GSs)) 

GSs = {S'j,{Su...,Sn),SB), n>l 
S’j, Si,Fs'r FIT-ARGi t>ai,S^ 

S'j, Sn, Fs h FIT-ARG„ t> ( 7 „, S^ 



Fra — Am-,Fr!i ) 

VariVN) = (Ms,GS^)) 

[M e Mod(rp) I M\b, e Ms, M\s, e Mi} c Mp 
GSm = (M'i,(Mi,...,M„),MB) 

S'j,Si,M'i,Mi,Fs,Fm hFIT-ARGi ^ M^ 



S}, Sn, M'l, M„, Fs, Fm h FIT-ARG„ ^ M^ 

Ma= GS^{{Mt,<7i),- ■ -AM 

Si,Sp,Mi,Mp,Fs,Fm I- fit-view VN FIT-ARGi . ..FIT-ARG„ ^ 

{M e Mod(rj u Ea) I M\Er eMi, M\s^ e Ma} 

A similar argument as for the non-generic case shows that Ai'|(<j' ocr)uids ^ 
M}, where M' = {M e Mod(i:j U | M\p, e Mi, M\b^ G Ma]- Then, 
M'ya'^oa)\jids^ Mp follows from ^ Ai] and M] C Mp. 



4.5 Symbol Lists and Mappings 

The semantics of a part of this section is necessarily dependent on the un- 
derlying basic specihcation framework formalized as an institution with sym- 
bols [39]. 
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4.5.1 Symbol Lists 



Symbol lists are used in hiding reductions. They can be identihers (matching 
to any symbol with the identiher as name) or fully-qualihed symbols. Sub- 
lists may also be qualihed with kinds (sort, function, predicate). 



SYMB-ITEMS : := symb-items SYMB-KIND SYMB+ 

SYMB-KIND : := implicit I sorts-kind | ops-kind | preds-kind 

SYMB ::= ID I QUAL-ID 

QUAL-ID ::= qual-id ID TYPE 

TYPE ::= OP-TYPE | PRED-TYPE 

Note that the described behavior is achieved by the dehnitions from 
Sect. 4.1.3; here, only symbol lists are assembled. 

CASL-specific rules for symbol lists 



k h SYMB > SY 

k G SYMB-KIND; then SYs G Sym is a symbol. 

I dent G ID 

implicit h Ident > {implieit^ Ident) 



implicit h qual-id / (total-op-type(sort-list s\ . . . Sn) s) > 

ft 

J (si 

implicit h qual-id / (partial-op-type(sort-list si . . . Sn) 5) > 

fP 

J (si ,...,Sn),S 

implicit h qual-id p (pred-type(sort-list 5 i . . . Sn)) > P{si,...,Sn) 

5 G ID 

sorts-kind h 5 > 5 
ops-kind \~ f > {fun, f) 

ops-kind h qual-id / (total-op-type(sort-list 5 i . . . s^) s) \> 

ft 

J {si,...,Sn) ,S 

ops-kind h qual-id / (partial-op-type(sort-list si . . . Sn) s) > 

fP 

J {si ,...,Sn),S 

preds-kind \~ p> {pred,p) 

preds-kind h qual-id p (pred-type(sort-list si . . . Sn)) > P{si,...,Sn) 



end of CASL-speeifie rules 
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h S YMB- ITEMS > SYs 
SYs C Sym is a set of symbols. 

k h SYMBi > SYi • • • A; h SYMB^ > SY n 
h symb-items k SYMBi • • • SYMB^ > • • • , SYn} 



A symbol list determines a set of qualified symbols, obtained from the listed 
symbols with reference to a given signature. 



SSYs h SYMB-ITEMS+ > SSYs' 

SSYs C SigSym is a set of signature symbols; then SSYs' C SSYs. 



h SYMB-ITEMSi > SYsi • • • h SYMB-ITEMS+ > SYsn 
SSYs h SYMB-ITEMSi • • • SYMB-ITEMS+ > 

{SY e SSYs I SSY matches some SY e SYsi U • • • U SYsn} 

4.5.2 Symbol Mappings 



Symbol mappings are used in translations, revealing reductions, htting ar- 
guments, and views. They can map identihers (matching to any symbol with 
the identiher as name) or fully-qualihed symbols. Sub-lists in the mapping 
may also be qualihed with kinds (sort, function, predicate). 



SYMB-MAP- ITEMS : := symb-map- items SYMB-KIND SYMB-OR-MAP+ 

SYMB-OR-MAP ::= SYMB | SYMB-MAP 
SYMB-MAP ::= symb-map SYMB SYMB 

Note that the described behavior is achieved by the dehnitions from 
Sect. 4.1.3; here, only symbol maps are assembled. 

CASL-specific rules for symbol maps 



k h SYMB-OR-MAP >r 

k G SymKind is a qualihcation kind; then r G SymMap is a symbol map. 



k h SYMB > SY 

k h SYMB qua SYMB-OR-MAP > {{SY, S^T)} 

k h SYMB > SY 
k h SYMB’ > SY' 



k h symb-map SYMB SYMB’ > {{SY, S^T')} 
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h SYMB-MAP-ITEMS> r 

r G SymMap is a symbol map. 

k h SYMB-OR-MAPi > n • • • kh SYMB-OR-MAP^ > 
h symb-map- items k SYMB-OR-MAPi • • • SYMB-OR-MAP^ > ri U • • • U 

end of CASL-specific rules 

A list of symbol maps determines a set of qualified symbols, obtained from 
the first components of the listed symbol maps with reference to a given 
signature, together with a mapping of these symbols to qualihed symbols 
obtained from the second components of the listed symbol maps. 



h SYMB-MAP- ITEMS* > r 

r G SymMap is a symbol map. 



h SYMB-MAP- ITEMSi > ri • • • h SYMB-MAP- ITEMS^ > 
h SYMB-MAP- ITEMSi • • • SYMB-MAP-ITEMS^ > ri U • • • U 

Note that SYMB-MAP- ITEMS+, as used in a RENAMING and a REVEALED, is just 
the case where n > 1. 

The transition to the level of qualihed symbols is performed in the seman- 
tics rules for translations, instantiation etc, using the dehnitions of Sect. 4.1.3. 



4.6 Compound Identifiers 



The components of a compound identiher may (but need not) themselves 
identify symbols that are specihed in the declared parameters of a generic 
specihcation. 



SORT-ID ::= ... | COMP-SORT-ID 

MIX-TOKEN ::= ... | COMP-MIX-TOKEN 

COMP-SORT-ID ::= comp-sort-id WORDS ID+ 

COMP-MIX-TOKEN ::= comp-mix-token ID+ 

Note that by the above additions to the grammar of the abstract syntax, 
the dehnitions of SORT- ID and ID have changed. 
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This also influences the semantic domains introduced in Sect. 2.3 and 3.1.1: 

Sort = SORT- ID 
FunName = ID l±) {em} l±) {pr} 

PredName = ID l±) {m(5) | 5 G Sort} 

Also note that in the dehnition of the set of symbols of a signature 
in Sect. 4.1.1, we have adopted the convention that SORT- ID is regarded 
as a subset of ID; hence comp- sort -id WORDS ID+ is identihed with id 
(comp-mix-token ID+). 

When a compound identiher is used to name a symbol in the body of a 
generic specihcation, the translation determined by htting arguments to pa- 
rameters applies to the components of the compound identiher as well. 



Given an identiher map /z C ID x ID, dehne ExtID{h) C ID x ID and 
ExtMIX-TOKEN(h) C MIX-TOKEN x MIX-TOKEN as the least relations satis- 
fying 

• /z C ExtID(h)^ 

• (id mixti . . .mixtn, id mixt[ . . .mixt'^) G ExtID(h) if (mixti^mixt[) G 
ExtMIX - TOKEN (h) or mixti = Tnixt[ for z = 1, . . . , rz and mixtj ^ mixt} 
for some 1 < j < rz, 

• ((comp-mix-token cii . . . cin), (comp-mix-token ci[ . . . ci'^)) G ExtMIX- 
TOKEN{h)^ provided that (cz^,czQ G ExtID{h) or cii = cz' for z = 
1, . . . , rz. 

The dehnition of Ext on page 196 has to be changed in the following way 
to accommodate compound identihers: Given a signature symbol map h C 
SigSym x SigSym^ 

Ext{h) = /z U IDAsSym{ExtID{h')Y^ 



where 

h' = {{Ident^ Ident') \ Ident^ Ident' G ID, 

{SSY.SSY') G /z, 

SSY matches IDAsSym{Ident) , 
SSY' matches IDAsSym{Ident')}^\ 



IDAsSym is applied to a binary relation by applying it component-wise. The 
union of h and IDAsSym{ExtID(ti)) may lead to a relation that is not a function 
(and, therefore, undehnedness of the instantiation of the generic specihcation, 
because the symbol map does not induce a signature morphism), if a compound 
identiher is mapped both explicitly by the htting morphism and implicitly by the 
extension mechanism. Note that this can happen in Casl only for sort symbols, 
since fully qualihed symbols are never identihers. 

Notice that h' may fail to be a function even if h is one, destroying the dehnedness 
of the instantiation of a generic specihcation. In Casl, this may happen, for 
example, if two different prohles of a function are mapped to different names, and 
the function name occurs in a compound identiher. 
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The embedding, projection and membership symbols em, pr and in{s) 
are not contained in ID and hence are not subject to the above extension 
mechanism for compound identihers. 

Subsort embeddings between component sorts do not induce subsort em- 
beddings between the compound sorts. 

Instantiation, however, does preserve subsorts. Compound identihers must 
not be identihed through the identihcation of components by the htting 
morphism. 



This behavior is automatically achieved by the use of a hnal signature 
morphism in the dehnition of signature morphism induced by a symbol map 
(which is used in the dehnition of the extension of a signature morphism along 
a signature extension, which is in turn used in the semantics of instantiations 
of generic specihcations). 




5 



Architectural Specification Semantics 



Architectural specifications are for imposing structure on models, expressing 
their composition from component units. 

The component units may all be regarded as unit functions: functions 
without arguments give self-contained units; functions with arguments use 
such units in constructing further units. 

The specihcation of a unit function indicates the properties to be assumed 
of the arguments, and the properties to be guaranteed of the result. In Casl, 
self-contained units are simply subsorted models as dehned in Chap. 3, and 
their properties are expressed by ordinary (perhaps structured) specihcations. 

Thus a unit function maps models of argument specihcations to models of 
a result specihcation. A specihcation of such functions can be simply a list of 
the argument specihcations together with the result specihcation. Thinking of 
argument and result specihcations as types of models, a specihcation of a unit 
function may be regarded as a function type. Such a specihcation describes 
the class of all persistent functions from compatible tuples of models of the 
argument specihcations to models of the result specihcation. 

An entire architectural specification is a collection of unit function specih- 
cations, together with a description of how the functions are to be composed 
to give a resulting unit. A model of an architectural specihcation is a collec- 
tion of unit functions with the specihed types or dehnitions, together with the 
result of composing them as described. 

In Sect. 5.1 we dehne semantic domains to model the concepts mentioned 
above. At the risk of stretching informality and neglecting precision, the vo- 
cabulary of key semantic notions to be introduced may be summarized as 
follows: 



concept 


static semantics 


model semantics 
(individual entities) 


model semantics 
(classes of entities) 


unit 


unit signature 


unit 


unit specihcation 


unit expression 


unit signature 


unit evaluator 


— 


unit declarations 
and dehnitions 


static unit context 


unit environment 


unit context 


architectural 

specihcation 


architectural 

signature 


architectural 

model 


architectural 

specihcation 
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Sections 5. 2-5. 5 then give static and model semantics for architectural specifi- 
cations, extending what was provided for basic and structured specifications. 
Finally, in Sect. 5.6, we refine the static analysis for architectural specifica- 
tions by giving an extended statie semanties^ which gathers considerably more 
static information and helps to discharge some of the requirements in the 
model semantics. 



5.1 Architectural Concepts 

To formally explicate the meaning of architectural constructs we need seman- 
tic domains to model the new notions hinted at above. 

First, some very preliminary definitions: 

UN e UnitName = SIMPLE- ID 
ASN e ArehSpeeName = SIMPLE- ID 
USN e UnitSpeeName = SIMPLE-ID 



Unit signatures, static unit contexts and architectural signatures carry static 
information necessary for ‘typing’ unit terms and expressions, unit declara- 
tions and definitions, and architectural specifications. 

An arehiteetural signature consists of a unit signature (for the result unit) 
together with a statie unit eontext: unit signatures for the component units 
named by unit names (see below). A unit signature gives a sequence of sig- 
natures^ for the unit arguments and a signature that extends their union for 
the result of the unit applications. For non-generic units this reduces to their 
(result) signature. To take into account constraints on applications of generic 
units, the signatures of their imports are stored as well. 

Ni , . . . , NJfi >N 

or G ParUnitSig = FinSeq{Sig) x Sig 

UE G UnitSig = ParUnitSig U Sig 



^ Unless explicitly stated otherwise, in this chapter signature means subsorted sig- 
nature, as introduced in Chap. 3. 

However, the semantics of Casl architectural constructs given here is inde- 
pendent of the underlying institution, provided the institution comes equipped 
with the structure introduced in Chap. 4 for the semantics of Casl structured 
specifications. The only extra assumptions we rely on here, which hold for the 
(subsorted) institution of CASL, are that the empty signature is included in all 
signatures, it has exactly one model, and that the sinks of signature morphisms 
given by signature unions are mapped by the model functor to sources that are 
jointly injective. 
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or 

or (i7^, UE) G ImpUnitSig = Sig x UnitSig 

Cs G StUnitCtx = UnitName ^ {ImpUnitSig U Sig) 
(C 5 , UE) or AE G ArchSig = StUnitCtx x UnitSig 

For a unit signature i7i, . . . , E^^E in ParUnitSig^ we require n > 1 and E to 
be an extension of i7i U . . . U E^. For a unit with import signature (i7^, UE) in 
ImpUnitSig^ we require UE G ParUnitSig and then, for UE = i7i, . . . , E^^E^ 
that E is an extension of U i7i U . . . U E^- We write for the empty static 
context. 

Units may be regarded as unit functions: functions without arguments give 
self-contained units, which are Casl models; functions with arguments use 
such units in constructing further units. 

A non-generic unit is just a Casl model. A generic unit over a unit signa- 
ture Ui, . . . , En^E is a (partial) function mapping sequences of compatible 
models over Ui, . . . , E^ to models over E. Models over Ui, . . . , E^ are com- 
patible if they can be amalgamated to a model over U . . . U E^. 

M G Unit(i:) = Mod(U) 

(Mi,...,Ag 

or M G CompMod(Ui, . . . , En) = 

. . . , M|^J I M G Mod(Ui U . . . U En)} 

F G Unit(Ui, . . . , En^E) = 

CompMod(Ui, . . . , En) Mod(U) 

U e Unit = Uuseunitstg Unit(C2:) 

A generic unit F G Unit(Ui, . . . , U^^U) is required to protect its argu- 
ments, i.e., for each (Mi,...,M^) G Dom{F)^ (F(Mi, . . . , M^))|x’i = Mi, 
..., (F(Mi,...,M,))|^^ =M,. 

Given compatible models (Mi, . . . , M^) G CompMod(Ui, . . . , En), we 
write Ml 0 ... 0 M^ for their amalgamation, i.e., the unique model in 
Mod(Ui U ... U En) such that (Mi 0 ... 0 Mn)\u-^ = Mi, ..., (Mi 0 
... 0 Mn)\un = M^ (uniqueness is ensured by the property of signature 
unions mentioned in footnote 1). For Adi C Mod(Ui), . . . ,A4n U Mod(U^), 
Adi0. . .0Adn = {M G Mod(Ui U . . . U U^) I M|^, G Mi , . . .M|^^ G Mn}- 

We extend this to ‘amalgamate’ models with generic units. 

Given a generic unit signature Ei, . . . , En^E and a signature E', we 
write (El , . . . , En^E) C E' for Ei, . . . , En^{E U E'). Then we say that a 
unit F G Unit(Ui, . . . , En^E) is compatible with a model M' G Mod(U') 
if for all M G Dom{F) such that M and M' are compatible, F{M) and M' 
are compatible as well. If this is the case, we define 

F 0 M' = {M ^ (F{M) 0 M') I M, M'are compatible, M G Dom{F)}, 
so that F 0 M' G Unit((Ui, . . . , En^E) U E'). 
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An architectural specification denotes a class of architectural models over 
an architectural signature. 

An architectural model over an architectural signature (C5, UU) consists of 
a (result) unit over the unit signature UU and a unit environment: a collection 
of (component) units over the signatures given in C5, named by the respective 
unit names. In Casl, all architectural specifications are deterministic in the 
sense that no environment determines more than one result unit. 

E G UnitEnv((75) C UnitEnv = UnitName ^ Unit 
(E, U) or AM G ArchMod{Cs, UE) = VnitEnv{Cs) x Unit(Ui:) 
ArchSpec(Ai:) = 6'e^(ArchMod(Ai:)) 

AM e ArchSpec = {JAueArchSig ArchSpec(Ar) 

A unit environment E is in UnitEnv((75) if Dom{E) E Dom{Cs) and for 
each UN G Dom{Cs) with Cs{UN) = (E^.UE) or Cs{UN) = UE, E{UN) G 

Unit(Ui:). 

Any architectural specification AA4 G ArchSpec is required to be func- 
tional: if for some E G UnitEnv, (E, UN i) G ANi and (E, UN 2) G ANi 
then UN I and UN 2 coincide. 

Unit specifications denote sets of units: 

UnitSpec(Ui:) = Set{Vnit{UE)) 

U e UnitSpec = \JuseUnitSig UnitSpec(C/r) 



Unit terms and unit expressions, used for instance to define the result units, 
denote unit evaluators which build a unit from a unit environment that 
records the units the term might involve. 



UnitEval(UT) = UnitEnv ^ Unit(UU) 

UEv e UnitEval = \JuE&Units^g UnitEval(?7r) 

ModEval(U) = UnitEnv ^ Mod(U) 

MEv G ModEval = Uz’eSig ModEval(U) 

We require that unit evaluators are monotone in the following sense: for UEv G 
UnitEval, if E G Dom(UEv) then for all E' E E, UEv{E') = UEv{E) 
(in particular E' G Dom(UEv) as well). Similar requirement is imposed on 
model evaluators in ModEval; note also that since signatures are in fact unit 
signatures as well, we have ModEval C UnitEval. 

Given any unit signature UE^ unit specification U C Unit(f/U), signature 
Efi and model evaluator MEv G ModEval(U^), the import extension oilA 
by MEv^ 

U 0 MEv C UnitEval(UT U E^) 

is the empty set if for some E G Dom(MEv) there is no F ^ U that is com- 
patible with MEv{E); otherwise U 0 MEv is the set of all unit evaluators 




111:5.1 Architectural Concepts 231 



UEv G UnitEval(CZ’ U such that Dom{UEv) = Dom{MEv) and for 
E G Dom{UEv)^ UEv{E) = F 0 MEv{E) for some F e U that is compat- 
ible with MEv{E). (Notice that due to the definitions of compatibility and 
amalgamation above, this notion applies to both non- generic and generic unit 
specifications.) 

Unit contexts are sets of unit environments, and thus record constraints on 
units as well as dependencies between them. 

One might think that all we need to know about units declared within an 
architectural specification are their individual specifications. However, since 
declared units may rely on imported units, non-trivial dependencies between 
them occur and should be taken into account. Consequently, unit contexts are 
sets of unit environments, thus recording constraints on as well as dependen- 
cies between units introduced. 

C G UnitCtx = 5 'e^(UnitEnv) 

Unit contexts are required to be ‘closed’ in the sense that if F G C then for 
all F' 0 F, F' G C as well. 

The ‘empty’ unit context = UnitEnv(C|') = UnitEnv imposes no 
constraints on units, and so consists of all unit environments. 

We use two auxiliary notations to manipulate unit contexts. Given any 
unit context C, unit name F7V, class U of units, and unit evaluator UEv with 
C C Dom{UEv)^ we define 

C[UNIU] = {EE{UN ^U}\E e C,U eU} 

and 

C[UN/UEv] = {EE{UN ^ UEv{E)} | F G C}. 

‘0’ denotes the ‘overwriting’ union of partial functions: given two unit en- 
vironments F and F', Dom{E 0 F') = Dom{E) U Dom{E') and then for 
UN G Dom{E 0 F'), (F 0 E'){UN) = E' {UN) if UN G Dom{E') while 
(F 0 E'){UN) = F( UN) otherwise. 

The entities used in the model semantics are required to be compatible with 
the corresponding entities of the static semantics. 

A unit context C G UnitCtx is compatible with a static unit context 
Cs G StUnitCtx if C C UnitEnv(C5). Moreover, given a unit context C 
that is compatible with a static unit context C5, and Cj G StUnitCtx and 
C' G UnitCtx, Cg and C' are compatible extensions of Cg and C if Dom{C^) 
and Dom{Cs) are disjoint, and CuC is compatible with CgUCj. Furthermore, 
UE G UnitSig and UEv G UnitEval are compatible additions to Cg and C if 
UEv G UnitEval(FF) and C C Dom(UEv). 

As introduced elsewhere (cf. Sect. 6.1), model (resp., static) global en- 
vironments Ejn (resp.. Eg) contain an architectural specification component 
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Am'^ ArchSpecName ^ ArchSpec (resp., As : ArchSpecName ^ ArchSig). 
Moreover, the definition of compatibility of static and model global en- 
vironments is extended here in the obvious way: Fg = (. ..,As,...) and 
Fm = (. are compatible only if Dom{As) = Dom{Am) and for 

each ASN e Dom{As), Am{ASN) e ArchSpec (As (^6'TV)). 

Similarly, model (resp., static) global environments Fj^ (resp., Fg) con- 
tain a unit specification component 7^: UnitSpecName ^ UnitSpec (resp., 

Tgi UnitSpecName ^ UnitSig). Moreover, the definition of compatibility of 
static and model global environments is further extended in the obvious way: 
Fg = (. . . , 7^, . . .) and F^ = (• • • , • • •) are compatible only if Dom(Tg) = 

Dom{%n) and for each USN e Dom{Tg), %n{USN) e VuitSpec{Tg{USN)). 

The rest of this chapter indicates the semantics of the constructs of archi- 
tectural specifications, extending what was provided for basic and structured 
specifications. 



5.2 Architectural Specification Definitions 



An architectural specification definition ARCH-SPEC-DEFN defines the name 
ARCH-SPEC-NAME to refer to the architectural specification ARCH-SPEC, ex- 
tending the global environment (which must not already include a definition 
for ARCH-SPEC-NAME). The local environment given to ARCH-SPEC is empty. 



ARCH-SPEC-DEFN ::= arch-spec-defn ARCH- SPEC-NAME ARCH-SPEC 
ARCH-SPEC : := BASIC-ARCH-SPEC I ARCH- SPEC-NAME 

ARCH-SPEC-NAME ::= SIMPLE-ID 



Fg h ARCH-SPEC-DEFN > Tj A, h ARCH-SPEC-DEFN ^ F^ 



Fg and F^ are compatible global environments; then F^ and F^ are compatible 
as well, and extend Fg and T^, respectively. 

Us = (0s 5 Vs, As, 7^) 

ASN 0 Dom{Qg) U Dom{Vg) U Dom{Ag) U Dom{Tg) 

Fg h ARCH-SPEC > AN 

Fg h arch-spec-defn ASN ARCH-SPEO (0s, Vs, As U {ASN AF},Fg) 

Um — (0m, Vttt,, Attt,, 7^) 

Ts, h ARCH- SPEC ^ AM 

Fg,Fm h arch-spec-defn ASN ARCH- SPEC ^ 

(0m, Vm, Am U {ASN ^ AM} ^ %n) 
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Fs h ARCH-SPEC > AE T;;, h ARCH-SPEC ^ AM 



Fs and Fm are compatible global environments; then ,4A^ G ArchSpec(A.Z'). 

Fs b BASIC-ARCH-SPEC t> AS 
Fs b BASIC-ARCH-SPECquaARCH-SPEO Ar 

Fs,Fm\- BASIC-ARCH-SPEC ^ AM 
Fs,Fm b BASIC-ARCH-SPEC qua ARCH-SPEC ^ AM 

ASN e Dom{As) 

{gs,Vs,As,%) b A^TVquaARCH-SPEO 



-T,, {Gm, Vm,Am, %n) b ASN qua ARCH-SPEC ^ Am{ASN) 



A basic architectural specification BASIC-ARCH-SPEC consists of a list of unit 
declarations and definitions together with a unit expression describing how 
such units are to be composed. A model of such an architectural specification 
consists of a unit for each unit declaration and definition in the list and the 
composition of these units as described by the result unit expression. 



BASIC-ARCH-SPEC ::= basic-arch-spec UNIT-DECL-DEFN+ RESULT-UNIT 
UNIT-DECL-DEFN ::=UNIT-DECL I UNIT-DEFN 
RESULT-UNIT : := result-unit UNIT-EXPRESSION 



Fs b BASIC-ARCH-SPEC \> AS A, b BASIC-ARCH-SPEC ^ AM 



Fs and F^ are compatible global environments; then AM G ArchSpec(Ai7). 

Fs b UNIT-DECL-DEFN+ t> Cg 
Fs,Cs>- RESULT-UNIT t> US 

Ts b basic-arch-spec UNIT-DECL-DEFN+ RESULT-UNIT t> ( C* , C/r) 

Fs b UNIT-DECL-DEFN+ t> Cg 
A, b UNIT-DECL-DEFN+ ^ C 
Fs,Fm,Cs,C ^ RESULT-UNIT ^ UEv 
rg,r„ b basic-arch-spec UNIT-DECL-DEFN+ RESULT-UNIT^ 

{(£;, UEv{E)) \ E e C} 



Fs b UNIT-DECL-DEFN+ t> Cg b UNIT-DECL-DEFN+ ^ C 



Fg and Fm are compatible global environments; then C is compatible with Cg 
too. 
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Cs, C® h UNIT-DECL-DEFNi t> (Cs)i 

fs, K UNIT-DECL-DEFN„ > (C«)„ 

Fs h UNIT-DECL-DEFNi . . . UNIT-DECL-DEFN„ > (C«)„ 

Fs, C® h UNIT-DECL-DEFNi t> (Cs)i 
Fs,Fm, C®, C® I- UNIT-DECL-DEFNi ^ Ci 

{Cs)n-1 ^ UNIT-DECL-DEFN„ > (C,)„ 

F„Fm, (C,)„_i, C„_i h UNIT-DECL-DEFN„ ^ C„ 

Fg, Fm I- UNIT-DECL-DEFNi . . . UNIT-DECL-DEFN„ ^ C„ 



Ts, Cs h UNIT-DECL-DEFN t> C^' T*, r„, C«, C h UNIT-DECL-DEFN ^ C 

Fg and F^ are compatible global environments, and C is compatible with Cs; 
then C and C'g are compatible, Cs ^ and C D C . 

Fs,Cs\- UNIT-DECL > C'g 

Fg,Cg^ UNIT-DECL qua UNIT-DECL-DEFN > Cg U Cj 

Fg,Fm, Cs, C h UNIT-DECL ^ C 
Fg,Fm,Cg, C h UNIT-DECL qua UNIT-DECL-DEFN^ C n C' 

Fs,Cg\- UNIT-DEFN > 

Fg,Cg\- UNIT-DEFN qua UNIT-DECL-DEFN > Cg U Cj 

Fg,Fm, Cg,C\- UNIT-DEFN ^ C 
Fg,Fm,Cs, C h UNIT-DEFN qua UNIT-DECL-DEFN^ C H C 



Fg,Cgh- RESULT-UNIT > US Fg,Fm, Cg,C\- RESULT-UNIT ^ UEv 

Fg and Fm are compatible global environments, and C is a unit context that is 
compatible with static unit context Cg; then UF and UEv G UnitEval(f7d7) 
are compatible additions to Cg and C . 

Fg, Cg h UNIT-EXPRESSION > [7d7 
Fg, Cg h result-unit UNIT-EXPRESSION t> C27 
Fg, Fm, Cg, C h UNIT-EXPRESSION ^ UEv 
Fg,Fm, Cg, C h result-unit UNIT-EXPRESSION^ UEv 

5.3 Unit Declarations and Definitions 

The visibility of unit names in architectural specifications is linear, and no 
unit name may be introduced more than once in a particular architectural 
specification. Declarations and definitions of units do not affect the global en- 
vironment: a unit may be referenced only within the architectural specification 
in which it occurs. 
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5.3.1 Unit Declarations 



A unit declaration UNIT-DECL provides a unit specification UNIT-SPEC and 
a unit name UNIT-NAME, which is used for referring to the unit in subsequent 
unit expressions. 

In addition, the UNIT- IMPORTED lists any units that are imported for the im- 
plementation of the declared unit (corresponding to implementing a generic 
unit function and applying it only once, to the imported units). The unit 
specihcation UNIT-SPEC is treated as an extension of the signatures of the 
imported units; see Sect. 5.4. 



UNIT-DECL ::= unit-decl UNIT-NAME UNIT-SPEC UNIT-IMPORTED 
UNIT-IMPORTED : := unit -imported UNIT-TERM* 

UNIT-NAME ::= SIMPLE-ID 



A, (U 5 h UNIT-DECL > C'^ A, C h UNIT-DECL ^ C 



Fg and are compatible global environments, and (7 is a unit context that 
is compatible with static unit context Cg'^ then C'^ and C are compatible 
extensions of Cg and C . 



Cg h UNIT- IMPORTED > 

F^.Fg hUNIT-SPEO A 
UN 0 Dom{Cg) 

Fg, Cg h unit-decl UN UNIT-SPEC UNIT- IMPORTED > {UN ^ U F)} 

Cg h UNIT- IMPORTED > F^ 

F^, Fg h UNIT-SPEC > 

UN 0 Dom{Cg) 

A, C 5 h unit-decl UN UNIT-SPEC UNIT- IMPORTED > 

[UN ^ {F^.F^FoU F^)} 

We treat non-generic and generic unit specihcations separately, as slightly 
different signature information is stored in static contexts in each case. How- 
ever, the uniform notation adopted for import extensions allows us to capture 
the model semantics for both cases in a single rule. 

Cg, C h UNIT-IMPORTED ^ MEv^ 

F^, {MEv\E) \ E e C}, Fm, Fg h UNIT-SPEC ^ U 
A, r^, C 5 , (7 h unit-decl UN UNIT-SPEC UNIT- IMPORTED ^ 

C^[UN/{U®MEv^)] 



Cg h UNIT- IMPORTED > A Cg,C^ UNIT- IMPORTED ^ MEv 
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(7 is a unit context that is compatible with static unit context Cg; then E 
and MEv are compatible additions to Cg and C . 

Cs h UNIT-TERMi > • • • (7^ h UNIT-TERM/, > Ek 

Cs h unit -imported UNIT-TERM^ , . . . , UNIT-TERM;, > EiU ...UEk 

By definition, the union of the empty family of signatures (considered here if 
A: = 0) is the empty signature. 

Cs, C h UNIT-TERMi ^ MEvi • • • (7^, (7 h UNIT-TERM/^ ^ MEvk 

for each E ^ C, MEvi{E)^ . . . , MEvk{E) are compatible 
(7s, (7 h unit -imported UNIT-TERM^ , . . . , UNIT-TERM;, ^ 

\E G C‘MEvi{E) 0 ... 0 MEvk{E) 



5.3.2 Unit Definitions 

A unit definition UNIT-DEFN defines the name UNIT-NAME to refer to 
the unit resulting from the composition described by the unit expression 
UNIT-EXPRESSION. 

UNIT-DEFN ::= unit-defn UNIT-NAME UNIT-EXPRESSION 



Eg, Cs^ UNIT-DEFN > C' A, (7^, (7 h UNIT-DEFN ^ C' 

Eg and Un are compatible global environments, and (7 is a unit context that 
is compatible with static unit context Cs; then (7j and C are compatible 
extensions of Cg and (7, and moreover, if two unit environments in (7 H (7' 
coincide on the unit names outside the domain of (7j then they are in fact 
equal. 

Eg, Cg h UNIT-EXPRESSION > i: 

UN 0 Dom{Cg) 

Eg, Cs 7 unit-defn UN UNIT-EXPRESSION > {UN ^ E} 

Eg.Cgh UNIT-EXPRESSION > 

UN 0 Dom{Cg) 

Eg, Cs h unit-defn UN UNIT-EXPRESSION > {UN ^ {^,E^E)} 

0 is the empty signature here: no imports are given to defined units. 

The above rules prevent unit names from being re-introduced in local unit 
definitions (in agreement with the requirement that each unit name is intro- 
duced only once in a given architectural specification). However, according 
to the usual visibility rules, the same unit name may be used for local unit 
definitions that are not in the scope of one another. 

Eg, Em, Cs, C h UNIT-EXPRESSION ^ UEv 
Eg, Em, Cs, C h unit-defn UN UNIT-EXPRESSION ^ (7*^ [ /77V/ 
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5.4 Unit Specifications 



A unit specification definition UNIT-SPEC-DEFN defines the name SPEC-NAME 
to refer to the unit specihcation UNIT-SPEC, extending the global environ- 
ment (which must not already include a dehnition for SPEC-NAME). The local 
environment given to UNIT-SPEC is empty, i.e., the unit specihcation is im- 
plicitly closed. 



UNIT-SPEC-DEFN : := unit-spec-def n SPEC-NAME UNIT-SPEC 



Fs h UNIT-SPEC-DEFN > Tj h UNIT-SPEC-DEFN > 



Fs and F^ are compatible global environments; then Tj and are compatible 
as well, and extend Fg and respectively. 

-Ts = {Qs'j^S'j '^S'j'^s) 

USN 0 Dom{Qs) U DomiVs) U Dom{As) U Dom{Ts) 

0, Fs h UNIT-SPEC > UF 

Fs \~ unit-spec-defn USN UNIT-SPEC > (gs,Vs,As,%'J{ USN ^ US}) 

Ffn = (^7715 Vttt,, w4.77t,, T^) 

0, Mod(0), Fs, Fm UNIT-SPEC ^ U 
iA, h unit-spec-defn USN UNIT-SPEC^ 

(Qm^ Vm, Am^'^m U { USN ^ U}) 

0 is the empty signature here, and Mod(0) is the (singleton) class of models 
over this signature. This captures the fact that UNIT-SPEC is being closed, so 
no dependencies on imports and hence on the unit environment can occur. 

A unit specihcation may be a unit type, the name of another unit specihca- 
tion, an architectural specihcation (either a reference to the dehned name of 
an architectural specihcation, or an anonymous architectural specihcation), 
or an explicitly-closed unit specihcation. In unit declarations, unit specihca- 
tions are used as extensions of imported units, see Sect. 5.3.1. 



UNIT-SPEC ::= UNIT-TYPE | SPEC-NAME | ARCH-UNIT-SPEC 

I CLOSED-UNIT-SPEC 



A, Fs h UNIT-SPEC > UF F^ , , Fs,Fm h UNIT-SPEC ^ U 



Fs and Fm are compatible global environments, F^ is a signature and A4^ F 
Mod(A^); then UF is a unit signature and U G Unit Spec (UA). 
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Cs I- UNIT-TYPE t> UE 
E^,rs\- UNIT-TYPE qua UNIT-SPEC > UE 

E^, M^, Us, Um I- UNIT-TYPE ^ U 
EI, M^, r, , h UNIT-TYPE qua UNIT-SPEC ^ U 

USN e Dom{%) 

rC (g* , Vs , A , Ts ) h USN qua UNIT-SPEC t> % ( USN) 



EI, MC r„ {Gm, Vm, Am, %,) h USN qua UNIT-SPEC ^ Tm{ USN) 

Us I- ARCH-UNIT-SPEC t> UE 
E^,Us h ARCH-UNIT-SPEC qua UNIT-SPEO Cr 

Us, Um I- ARCH-UNIT-SPEC ^ U 
E^, M, Us, Um I- ARCH-UNIT-SPEC qua UNIT-SPEC ^ U 

Us h CLOSED-UNIT-SPEO Cr 
E^,Us h CLOSED-UNIT-SPEC qua UNIT-SPEC t> UE 

Cs, h CLOSED-UNIT-SPEC ^ U 
E^,M^,rs,rm I- CLOSED-UNIT-SPEC qua UNIT-SPEC ^ U 



5.4.1 Unit Types 



A unit type lists argument specifications and the result specification. A unit 
satisfies a unit type when it is a persistent function that maps compatible 
tuples of models of the argument specifications to models of their extension 
by the result specification. 



UNIT-TYPE ::= unit -type SPEC* SPEC 



E, Us h UNIT-TYPE > UE E^ , , Us, Fm b UNIT-TYPE ^ U 



Fg and F^ are compatible global environments, E^ is a signature and C 
Mod(Z''^); then UE is a unit signature and U G UnitSpec(?7Z'). 

E^,Fs h SPEC > U 
E^ , Fg b unit -type SPEC t> E 

E^, M^, Fg, Fm b SPEC ^ M 
E^ , , Fg, Fm b unit-type SPEC ^ M. 
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0 , Fs h SPECi \> Si ■■■ 0, A h SPEC„ t> S„ 

s^ u Siu . . .u s„,rs\- SPEC t> r 
S^ , Fg h unit-type SPECj^ . • • • .SPEC„ SPEC t> Si, . . . , S„^S 

0, Fg h SPECi > Si ■■■ <D,Fg\- SPEC„ t> Sn 

0, Mod(0), Fg, F^ h SPECi ^ Mi ■■■ 0, Mod(0), Fg,F^'r SPEC„ ^ Mn 
u u . . . u r„, Ts h SPEC t> s 

A4o = 0 .Adi 0 • • • 0 Min 

U Ti U . . . U Sn,Mo, Fg,Fml- SPEC ^ M 
S^,M^,Fg,Fm I- unit-type SPEC^ , . . . , SPEC„ SPEC ^ 

{F e Unit(ri, . . . , S„^S) I for some e M^, 

for all M e Mo with M|^/ = M\ {M\e,, ■ ■ ■ , M\sJ £ Dom{F), 
F{M\s„...,M\s,„) eM, and {F{M\e„ ■ ■ ■ , M\eJ)\e^ = M^} 

Imports are not taken as local environment for parameter specifications here, 
in accordance with the interpretation of imports as ‘already instantiated pa- 
rameters’. 

The semantics of SPEC is given in Sect. 4.2. 

5.4.2 Architectural Unit Specifications 

A unit satisfies ARCH-UNIT-SPEC when it is the result unit of some model of 
the architectural specification ARCH- SPEC. 

ARCH-UNIT-SPEC : := arch-unit-spec ARCH-SPEC 



Fs h ARCH-UNIT-SPEC > UE A, h ARCH-UNIT-SPEC ^ U 



Fg and are compatible global environments; then UE is a unit signature 
and U G Unit Spec (f/A). 

Fg h ARCH-SPEC > {Cg, UE) 

Fg h ARCH-SPEC qua ARCH-UNIT-SPEO UA 

Fg,Fm^ ARCH- SPEC ^ AM 

Fg,Fm k ARCH-SPEC qua ARCH-UNIT-SPEC ^ {U \{E, F)eAM for some E} 
5.4.3 Closed Unit Specifications 



A closed unit specification CLOSED-UNIT-SPEC determines the same type as 
UN IT- SPEC determines in the empty local environment. 
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CLOSED-UNIT-SPEC : := closed-unit-spec UNIT-SPEC 



Fs h CLOSED-UNIT-SPEC > UE A, h CLOSED-UNIT-SPEC ^ U 



Fg and Fj^ are compatible global environments; then UE is a unit signature 
and U G Unit Spec (bA7). 



0,T5 h unit-speo Ui: 

Fs h closed UNIT-SPEC > UE 

0, Mod(0), Fs, Fm UNIT-SPEC ^ U 
Fs, Fm closed UNIT-SPEC ^ U 



5.5 Unit Expressions 



A unit expression (with some unit bindings) describes a composition of units 
declared (or defined) in the enclosing architectural specification. The result 
unit is a function, mapping the arguments specified by the unit bindings (if 
any) to the unit described by the unit term UNIT-TERM. 



UNIT-EXPRESSION ::= unit -express ion UNIT-BINDING* UNIT-TERM 
UNIT-BINDING : := unit-binding UNIT-NAME UNIT-SPEC 



Fs,Cs^ UNIT-EXPRESSION > UE 

Fs,Fm, Cs, C h UNIT-EXPRESSION ^ UEv 

Fs and Fm are compatible global environments, and (7 is a unit context that 
is compatible with static unit context Cg', then UE and UEv are compatible 
additions to Cg and C. 



Eg, Cs h UNIT-TERM > i: 

Fs, Cg unit-expression UNIT-TERM > E 

rg,rm,Cs,C ^ UNIT-TERM ^ MEv 
Eg, Em, Cs, C h unit-expression UNIT-TERM ^ MEv 

Eg h UNIT-BINDINGi > {UNi,Ei) ••• Eg h UNIT-BINDING^ > {UNn,En) 
UNi , . . . , UNn are distinct { UNi, . . . , UNn} H Dom{Cs) = 0 
Cl = {UNi^ El,..., UNn ^ En} 

Eg, Cs U Cl h UNIT-TERM > EiU . . .U En U E 

Fs, Cs h unit-expression UNIT-BINDING^, . . . , UNIT-BINDING^ UNIT-TERM 

l> El, . . . , En ^E 
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Fs h UNIT-BINDINGi t> {UNi, Si) ■■■ h UNIT-BINDING„ > {UN„, r„) 
rs,rm I- UNIT-BINDINGi ^ {UNi,Mi) 

r,,r„ h UNIT-BINDING„ ^ (UiV„,M„) 

S^ = Si U . . . U S^ = .M-i 0 ... 0 

UN^ ^ Dom{Cs)u{UNi,..., UN„} 

Cl = { UN^ ^ SP, UNi ^ Si,..., UNn ^ Sn} 

C' =C^[ UN’" /M^\ [ UNi/{\E-E{ UN’")\s^ )]...[ UNn/{XE-E{ UN^)\s „, )] 
Es,rm,CsU Cl,C n C' \- UNIT-TERM ^ MEv 
for all E e Cn C',MEv{E)\sP = E{UN’") 

UEv G UnitEval(i7i, . . . , Sn^S) is such that Dom{ UEv) = C and 
for E eC, 

{Ml, . . . , M„) G Dom{ UEv{E)) C CompMod(ri, . . . , S„) iff 
E + { UN’’ (Ml 0 ... 0 M„), UNi Ml,..., UN„ M„} e C D C 
and then for (Mi, . . . , M„) G Dom{ UEv{E)), 

UEv{E){Mi,...,M„) = 

MEv{E 0 { UN’’ (Ml 0 ... 0 M„), UNi Mi,..., UNn M„}) 
r,,Enn,C,,Ch- 

unit-expression UNIT-BINDING^ , . . . ,UNIT-BINDING„ UNIT-TERM 

^ UEv 

The trick with the use of a new unit name UN’’ restricts attention to envi- 
ronments with formal parameter names denoting compatible models only. 



Eg h UNIT-BINDING t> ( UN, S) T*, h UNIT-BINDING ^ ( UN, M) 



Eg and Fm are compatible global environments; then UN is a unit name (the 
same for the static and model semantics) and M. C Mod(T'). 

0,r« h UNIT-SPEO r 

Eg h unit-binding UN UNIT-SPEC t> ( UN, S) 

The above rule imposes the restriction that only non-generic units can be 
bound in unit bindings. 

0, Mod(0), Eg, Em b UNIT-SPEC ^ M 
Eg,Emy- unit-binding UN UNIT-SPEC ^ ( UN, M) 
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5.5.1 Unit Terms 



Unit terms provide counterparts to most of the constructs of structured 
specifications: translations, reductions, amalgamations (corresponding to 
unions), local unit definitions, and applications (corresponding to instanti- 
ations) - but with a crucially different semantics. For units, enough sharing 
is required so that the constructs as applied to the given units will always 
produce results. Sharing between symbols is understood here semantically: 
two symbols share if they coincide semantically. See Sect. 5.6 for further 
elaboration on this issue. 

Taking the unit type of each unit name from its declaration, the unit term 
must be well-typed. All the constructs involved must get argument units 
over the appropriate signatures. 



UNIT-TERM ::= UNIT-REDUCTION | UNIT-TRANSLATION | AMALGAMATION 
I LOCAL-UNIT I UNIT-APPL 



Fs.Cs^ UNIT-TERM > U U h UNIT-TERM ^ MEv 



Eg and are compatible global environments; (7 is a unit context that 
is compatible with static unit context Cg'^ then E and MEv are compatible 
additions to Cg and C. 

Rules elided. 

Due to the semantic verification condition in the model semantics for ap- 
plications, in general we may not be able to derive Cg^ C \~ UNIT-TERM ^ MEv 
even if the static semantics works {Cg h UNIT-TERM > E can be derived). 

The only reason to keep the global environments available for the semantic 
of unit terms is that they are needed for the semantics of unit expressions in 
local definitions (Sect. 5.5.1). 

Unit Translations 



A unit translation allows some of the unit symbols to be renamed. Any 
symbols that happen to be glued together by the renaming must share. 



UNIT-TRANSLATION : := unit -translation UNIT-TERM RENAMING 



Eg, Cg h UNIT-TRANSLATION > U 

Eg,Em,Cg,C h UNIT-TRANSLATION ^ MEv 

Eg and Un are compatible global environments; (7 is a unit context that 
is compatible with static unit context Cg; then E and MEv are compatible 
additions to Cg and C. 
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r«, Cs h UNIT-TERM > T 
r h RENAMING > cr.E^E’ 

Fg, Cs unit-translation UNIT-TERM RENAMING t> 

r«, Cg h UNIT-TERM > T 
rs,rm,Cs,C ^ UNIT-TERM ^ MEv 
E h RENAMING > cr.E^E’ 

for all E £ C, there exists a unique M' G Mod(i7') with M'|o- = MEv{E) 
Eg, Em, Cg, C h unit-translation UNIT-TERM RENAMING^ 

{E ^ M' \ E e C,M' e Mod(r'),M'|^ = MEv{E)} 

The semantics of RENAMING is given in Sect. 4.2.1. 

Unit Reductions 

A unit-reduction allows parts of the unit to be hidden and other parts to be 
simultaneously renamed. 



UNIT-REDUCTION : := unit -reduct ion UNIT-TERM RESTRICTION 



Eg.CgV- UNIT-REDUCTION t> E Eg,Em,Cg,C h UNIT-REDUCTION ^ MEv 



Eg and Em are compatible global environments; U is a unit context that 
is compatible with static unit context Cg; then E and MEv are compatible 
additions to Cg and C. 



Eg,Cg'^ UNIT-TERM > T 
( 0 , E) h RESTRICTION > a-.E'^E" 

Eg, Cg h unit-reduction UNIT-TERM RESTRICTION > 

Cs h UNIT-TERM > T 

Eg,Em, Cg, C \- UNIT-TERM ^ MEv 
( 0 , E) h RESTRICTION > a:E'^E" 

for all E eC, 

there exists a unique M" G Mod(A'") with M"\a- = MEv{E)\j:f 
Eg, Em, Cg, C h unit-reduction UNIT-TERM RESTRICTION ^ 

{E ^ M" \ E e C,M" G Mod{E''),M''\^ = MEv{E)\e'} 

The semantics for RESTRICTION is given in Sect. 4.2.2. 
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Amalgamations 



An amalgamation produces a unit that consists of the components of all the 
amalgamated units put together. Compatibility of the unit terms must be 
ensured. 



AMALGAMATION : := amalgamation UNIT-TERM+ 



Fs, Cs h AMALGAMATION > A, C h AMALGAMATION ^ MEv 



Eg and Em are compatible global environments; C is a unit context that 
is compatible with static unit context Cg; then E and MEv are compatible 
additions to Cg and C . 

Eg,Cg^ UNIT-TERMi > • • • A, h UNIT-TERM^ > 

Eg, Cg h amalgamation UNIT-TERM^ , . . . , UNIT-TERM^ > EiU ...UEn 

Fg, Em, Cg, C h UNIT-TERMi ^ MEvi 

rg,Fm,Cg,C ^ UNIT-TERM^ ^ MEvn 
for all E ^ C, MEvi{E ), . . . , MEvn{E) are compatible 
Eg,Fm, Cg, C h amalgamation UNIT-TERM^ , . . . , UNIT-TERM^ ^ 

\E G C‘MEvi{E) 0 ... 0 MEvk{E) 



Local Units 



This construct allows for naming units that are locally defined for use in a 
unit term, these units being intermediate results that are not to be visible 
in the models of the enclosing architectural specification. 



LOCAL-UNIT ::= local-unit UNIT-DEFN+ UNIT-TERM 



Eg, Cgh LOCAL-UNIT > i: rg,Fm,Cg,C h LOCAL-UNIT ^ MEv 



Eg and Fm are compatible global environments; C is a unit context that 
is compatible with static unit context Cg; then E and MEv are compatible 
additions to Cg and C. 



Eg, Cgh UNIT-DEFNi >((75)1 

Fs, C,U{Cs)iU...LI ( 0 )„-i h UNIT-DEFN„ t> (Cs)„ 

Fs, Cs U (Cg)! U . . . U {Cs)n I- UNIT-TERM > T 
Fs, Cs h local-unit UNIT-DEFNi , . . . ,UNIT-DEFN„ UNIT-TERM > T 
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Fs, Cg h UNIT-DEFNi t> (Cs)i 
rs,rm,Cs,C \- UNIT-DEFNi ^ Cl 

n, C, U {Cs)i U . . . U {Cs)n-1 ^ UNIT-DEFN^ > {Cs)n 

Cs u (^5)1 u ... u {Cs)n-i.cr\ n ... n Cn-i h 

UNIT-TERM^ ^ Cn 

Fs^Tm, Cs u ((75)1 u . . . u [Cs)n, c n Cl n . . . n (7n h unit-term ^ mev 
ME v' = {E ^ MEv{E + E^) \ 

E e C, Dom{E^) = Dom{C^), {E ^ E^) e C n C^} 

Es.Em^Cs.C^ 

local-unit UNIT-DEFNi, . . . ,UNIT-DEFN^ UNIT-TERM ^ MEv' 

Notice that by the semantic properties of unit dehnitions, for each E there is 
at most one E^ with Dom{E^) = Dom{C^) such that {E + E^) G C H . 



Unit Applications 



A unit application UNIT-APPL refers to a generic unit named UN IT- NAME that 
has already been declared or dehned in the enclosing architectural specihca- 
tion, providing a htting argument for each declared parameter. The htting 
argument hts the argument unit given by the unit term to the corresponding 
formal argument for the generic unit via a signature morphism determined 
by the symbol mapping. The signature morphism is obtained in the same 
way as for generic specihcations. Each htting argument unit is required to 
be a model of the corresponding argument specihcation. 



UNIT-APPL ::= unit-appl UNIT-NAME FIT-ARG-UNIT* 
FIT-ARG-UNIT ::= f it-arg-unit UNIT-TERM SYMB -MAP -ITEMS* 



Es.Cs^ UNIT-APPL > A C h UNIT-APPL ^ MEv 



Eg and are compatible global environments; C is a unit context that 
is compatible with static unit context C 5 ; then E and MEv are compatible 
additions to Cg and C . 



Cg{UN) = E 

Fg^ Cs \- unit-appl UN > E 



Eg^Fm, Cg, C h unit-appl UN ^ {E ^ E{UN) \ UN G Dom{E)} 
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IJP = \J Ei\J . . ,\J Sn 
Ei,Fs, Cs h FIT-ARG-UNITi > ar.Ei^E^ 

En, Cs h FIT-ARG-UNIT„ > a^-En^E^ 

E^ = E^ U Efu ...U E^ a^ = {idsi U cii U . . . U ct„) : ^ 

a^{A): E — > {E^ U E^(A)), where A:E^^E is the signature extension 

Cs, Cs h unit-appl UN FIT-ARG-UNITj , . . . ,FIT-ARG-UNIT„> 

E^\JE^{A) 

See Sect. 4.1.3 for the definition of <j^{A), the extension of a signature mor- 
phism along a signature extension. 

Cs(c/iv) = (^^(^l,...,^„^^)) 

E^ = E^ \J Ei\J . . ,\J En 
El, Us, Cs h FIT-ARG-UNITi > ai'.Ei^Ef^ 

El, Us, Um, Cs, C h FIT-ARG-UNITi ^ MEvi 

En, Es, Cs h FIT-ARG-UNIT„ > an-En^E^ 

En, Fs, Fyn, Cs, C I- FIT-ARG-UNIT„ ^ MEvn 
for all E e C,{MEvi{E%y,...,MEvn{E)\n„) G Dom{E{UN)) 

\J S^\J ...\JE^ = {id SI U (71 U . . . U (7„) : ^ 

a^{A): E — > {E^ U E^{A)), where A:E^^E is the signature extension 

for all E £ C, there exists a unique M G Mod(i7"^ U E^{A)) 
such that M\sa = MEvi{E), . . . , M|^a = MEvn{E) and 

M|4(4) = E{UN){MEvi{E%y,...,MEvn{E%,^) 

MEv = {E^M\EeC,Me Mod(Z’'4 u E^{A)), 

M\sa = MEvi{E), . . . , M\sa = MEvn{E), 
MCA(^)=E{UN){MEvi{E%y,...,MEvn{E%J} 
Fs,Fm,Cs,CV- 

unit-appl UN FIT-ARG-UNITi , . . . , FIT-ARG-UNIT„ ^ MEv 



E,Fs, Cs h FIT-ARG-UNIT> 

E,Fs,Fyn,Cs,C \- FIT-ARG-UNIT ^ MEv^ 

Fs and Fm are compatible global environments; C is a unit context that 
is compatible with static unit context C^; then a: E ^ E^ is a signature 
morphism, and E^ and MEv^ are compatible additions to Cs and C. 

Fs,Cs\- UNIT-TERM t> E^ 
h SYMB-MAP- ITEMS* > r 



E,Fs, Cs h fit-arg-unit UNIT-TERM SYMB-MAP-ITEMS* t> 
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See Sect. 4.1.3 for the definition of the signature morphism 

induced by the symbol map r. 

rs.Fm.Cs.C ^ UNIT-TERM ^ MEv 

E,rs,Em,Cs,C h fit-arg-unit UNIT-TERM SYMB-MAP- ITEMS* ^ MEv 
The semantics of SYMB-MAP- ITEMS* is given in Sect. 4.5.2. 



5.6 Extended Static Semantics 

The static semantics of architectural specifications given above performs only 
a rough static analysis, collecting only very limited static information from 
what is potentially available about units being defined by unit terms. Conse- 
quently, many conditions (notably those concerning amalgamability of models 
built by unit terms) that one would expect to be discharged by a static seman- 
tics have to be checked in the rules for the model semantics. On one hand, this 
gives extra fiexibility: the model semantics by definition stores all the infor- 
mation we have about units. On the other hand though, this is inconvenient in 
practice, because a static analysis tool that follows the static semantics would 
fail to detect some errors that could be caught using typechecking methods, 
without resorting to a theorem prover. 

In this section we present an extended static semantics for architectural 
specifications, which gathers considerably more information than before, and 
therefore allows for simplification of the model semantics, with some condi- 
tions removed. To make the simplification visible below we will repeat the 
rules of the model semantics, explicitly crossing out the conditions that can 
be removed thanks to the extended static analysis. The extended static se- 
mantics, although presented here in a technically somewhat different form, is 
essentially equivalent to the one worked out in [62] for a simplified fragment 
of Casl architectural specifications. 

In a way, the extended static semantics is more restrictive than necessary: 
there are cases where the extended static semantics fails while the seman- 
tics given in the previous sections produces a valid result (see Sect. 5.6.6 for 
the statement of some form of correctness of the extended static semantics). 
These cases are rare in practice and typically indicate that some conditions 
follow, often incidentally, from subtle constraints on the models imposed by 
specifications. We recommend therefore that Casl support tools realize the 
extended analysis as much as possible^, and when it fails issue a warning to 
the user that (s)he has to rely on more powerful tools (e.g., proof mechanisms) 
to ensure correctness of the specification (or, perhaps more likely, modify the 
specification). 

^ The conditions used in extended static semantics are undecidable in general; 
however, there are efficient methods to check them in most cases of interest - see 
[31] for a more complete analysis. 
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5.6.1 Architectural Concepts 



Signature diagrams are used to keep track of dependencies between units. 
Diagram nodes correspond to the units declared or built so far and record 
their signatures. Diagram edges are labelled by signature morphisms that in- 
dicate how the unit corresponding to the source of each edge is incorporated 
as a part of the unit corresponding to its target. 

The extended static semantics keeps track of the sharing information on 
units stored in unit environments. Therefore, a more complicated form of 
static contexts is necessary: rather than just naming signatures of these units, 
they also store a diagram of their signatures, keeping track of the mutual 
dependencies between units. 

A signature diagram D : Shape{D) Sig is a functor from its shape (small) 
category Shape{D) to the category Sig of signatures. We will often identify 
the shape category with its graph. We write Nodes {D) for the set of objects 
of Shape{D) and Edges {D) for the set of its edges, using the notation e: p^q 
for e G Shape{D) and p^q ^ Nodes (D) to indicate the source and target of an 
edge e. Consequently, for p G Nodes (D)^ D{p) is a signature and for e: p^q 
in Shape{D)^ ^{p) ^ ^{q) is a signature morphism. 

Although we do not rely on this here, it is worth noticing that the shapes 
of all diagrams we consider are in fact dags (directed acyclic graphs). 

It is convenient to assume that both nodes and edges of the diagrams 
considered come from a given infinite set Item; to make the choice of ‘new’ 
nodes and edges deterministic, we may assume that Item comes equipped with 
a fixed enumeration - then ‘new’ always means ‘first not used as yet’. 

Diag denotes the class of all signature diagrams. 

We say that a diagram D G Diag extends D' G Diag (or that D' is a 
subdiagram of D) if Shape {D') is a subcategory of Shape {D) and D' coincides 
with D on nodes and edges in Shape{D). Somewhat informal statements that 
one diagram extends another by a (new) node or by an edge will be used with 
the obvious meaning. 

Diagrams i G X (for an arbitrary set of indices X) disjointly extends 
D' if each Di^ i G X, extends D' and moreover, for all distinct i^j G X, 
Shape {Di) H Shape {Dj) = Shape {D^). If this is the case then the union 
Di is well-defined, its shape Shape{[j-^j- Di) is the obvious free closure 
of Shape(Di)^ and the union extends D' . 

Whenever such a ‘disjoint ness’ requirement occurs in the rules below, it 
may be eliminated by the appropriate choices of new nodes and edges in the 
diagrams involved. Spelling this out in the semantics would require carrying 
around the set of nodes and edges already used - rather than cluttering the 
rules and judgements with this extra parameter, we state the disjointness 
requirement explicitly when necessary. 
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The extended static semantics takes signatures from signature diagrams, 
indicating for each non-generic unit the corresponding node in the current 
signature diagram, in which the unit signature is recorded. 

In the extended static semantics, unit contexts carry the diagram of de- 
pendencies between unit signatures. The signatures of non- generic units (both 
those stored in environments as well as those imported by generic units) are 
‘based’ on this diagram, and are given by reference to its nodes. 

Bg G StBasedUnitCtx = UnitName ^ Item 

(P^ • • • 5 

or (p, 

or (p, UE) G BasedParUnitSig = Item x ParUnitSig 

Ps G StParUnitCtx = UnitName ^ BasedParUnitSig 
[Pg^Bg^D) or Cg G ExtStUnitCtx = 

StParUnitCtx x StBasedUnitCtx x Diag 

The following requirements are imposed on any extended static unit context 
[Pg^Bg^D) in ExtStUnitCtx: 

• the domains of Pg and Bg are disjoint; 

• for each UN G Dom{Bg)^ Bg{UN) is a node in and 

• for each UN G Dom{Pg) with {p^UE) = Pg{UN)^ p is a node in D and 
{D{p),UE) G ImpUnitSig. 

There is an obvious map etx: ExtStUnitCtx^ StU nit Ctx given by 

etx{Pg,Bg,D) = {/77V ^ D{Bg{UN)) \ UN G Dom{Bg)}U 

{UN {D{p),UE) I UN G Dom{Pg),Pg{UN) = (p,UE)}. 

We dehne the projection dgm: ExtStUnitCtx ^ Diag by dgm{Pg, Bg^D) = D. 
We write Dom{Cg) for Dom{etx{Cg)) (spelling this out: Dom{Pg, Bg, D) = 
Dom{Pg) U Dom{Bg)), and Cf for the empty extended static context (where 
both maps and the diagram are empty: Cf = ({},{},{}))• 

We say that {P'^, B'^, D') extends (Pg,Bg,D) if D' extends D, Pg C P', 
and Bg C Bg. 

{Pg, Bg, D') is an admissible addition to {Pg, Bg,D) if they have disjoint 
domains (i.e., Dom{Pg, Bg,D') H Dom{Pg, Bg,D) = 0) and D' extends D. We 
then write {Pg, Bg, D) E {P'g, B'g, D') for (P^ U P', U P', P>')- 

The entities used in the model semantics are required to be compatible with 
the corresponding entities of the extended static semantics. 

Given a diagram D G Diag, we write Mod(P) for the class of all 
Nodes {D)-indexed model families consistent with D: {Mp)p^j^odes(D) is eon- 
sistent with D if for each p G Nodes {D), Mp G Mod(P(p)) and for each 
e: p^q in D, Mp = Mq\D(e)^ 
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As for static contexts in the previous sections, for any extended static 
context Cs, we define a class UnitEnv(Cs) C UnitEnv of unit environments. 
Let Cs = {Ps, Bs, D). Then E G UnitEnv(Cs) if Dom{E) E DomiCs) and 
there exists a model family (Mp)p^TVodes(i:)) ^ ~M.od{D) such that: 

• for all UN G Dom{Bs)^ E{UN) = Mb^(un)‘-, and 

• for all UN G Dom\Ps) with (p, UE) = Ps{UN), E{ UN) G Unit(Lr) and 

E{UN) is compatible with Mp. 

The definition of compatibility of a unit context with a static context carries 
over to the extended case: a unit context C G UnitCtx is compatible with an 
extended static context Cs G ExtSt UnitCtx if C C UnitEnv (Cg). 

Moreover, given a unit context C compatible with an extended static con- 
text Cs, and C'g G ExtStUnitCtx and C' G UnitCtx, C' and C' are compatible 
extensions of Cs and C if C' is an admissible addition to Cs and CuC is com- 
patible with CsPCg. Furthermore, given a diagram D' that extends dgm(Cs)^ 
a node p G Nodes{D')^ and a model evaluator MEv^ {p^E^D') and MEv 
are compatible additions to Cs and C if D'{p) = E and for some unit name 
UN 0 Dom{Cs), C[UN/MEv] is compatible with Cs + {{}AUN ^ p},D'). 
Similarly, given a diagram D' that extends dgm(Cs)^ a node p G Nodes {D')^ 
a generic unit signature UE^ and a unit evaluator UEv^ (p, UE^D') and UEv 
are compatible additions to Cs and C if D\p) is a subsignature of the result 
signature in UE and for some unit name UN 0 Dom{Cs)^ C[UN / UEv] is 
compatible with Cs + ({ UN \-^ (p, UE)}, {}, D^). 

Amalgamability requirements are formulated statically, with reference to the 
signature diagram. 

Given a diagram D G Diag, a sink a on a set of nodes K C Nodes {D) is a 
signature E together with a family of signature morphisms api D{p) ^ E, p ^ 
K. We say that D ensures amalgamability along a = (E, {ap : D{p)^ E)p^k) 
if for every model family (Mg)g^TVodes(i:)) consistent with D there exists a 
unique model M G Mod(i7) such that for all p G K, = Mp. We use 

slightly different but hopefully self-explanatory variants of this terminology 
and notation for special cases when K consists of one or two elements, is given 
by enumeration, etc. 

Although we have formulated this amalgamability condition in terms of 
model families, it is an essentially static property: the class of model families 
considered is not restricted by any axioms, but only by signatures and mor- 
phisms between them. This static nature of the condition may be made explicit 
by embedding the underlying institution into an institution that admits amal- 
gamation. For Casl this can be given by considering so-called enriched Casl 
signatures, where, roughly, one admits an arbitrary category, rather than just 
a pre-order, of subsort embeddings. See [62] for details. 

Given the above definitions, we define below the extended static seman- 
tics, enriching the static semantics above by the analysis of sharing between 
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units. The judgements of this extended static semantics will be written using 

the symbols h ^ As with the semantics above, we give the rules 

for extended static semantics for all constructs of the abstract syntax. The 
headings corresponding to each syntactic category will be given, quoting also 
the corresponding judgements of the semantics above. We recall the condi- 
tions linking the static and model semantics from the previous sections, and 
add to these formal properties of the extended static semantics as well as 
conditions linking the extended static semantics with the static and model se- 
mantics above. Many of the rules of the extended static semantics differ only 
in uninteresting details from the rules of the static semantics given above. The 
essential changes are mainly in the rules for the static analysis of unit terms. 

For the sake of readability, we recall the abstract syntax, although we skip 
the explanation included above. 

Finally, in Sect. 5.6.6 we discuss correctness and completeness of the ex- 
tended static semantics w.r.t. the simple static and model semantics given in 
the previous section. 

5.6.2 Architectural Specification Definitions 

ARCH-SPEC-DEFN ::= arch-spec-defn ARCH- SPEC-NAME ARCH-SPEC 
ARCH-SPEC : := BASIC-ARCH-SPEC I ARCH- SPEC-NAME 



Fs h ARCH-SPEC-DEFN > Tj A, h ARCH-SPEC-DEFN ^ 

Fs h ARCH-SPEC-DEFN ^ Tj 



Fs and F^ are compatible global environments; then F^ and F^ are compatible 
as well, and extend Fg and respectively. 

If Fs h ARCH-SPEC-DEFN ^ Tj then Fg h ARCH-SPEC-DEFN > F^. 

-Ts = {Qs'j^S'j '^S'j'^s) 

ASN 0 Dom{Qs) U Domiys) U Dom{Ag) U Dom(Ts) 

Fg h ARCH-SPEC AF 
Fg h arch-spec-defn ASN ARCH-SPEC ^ 

{gg,Vg,AgA{ASN ^ AF},Tg) 



Fg h ARCH-SPEC > AA Fg,Fm^ ARCH-SPEC ^ AM 

Fg h ARCH-SPEC AF 



Fs and are compatible global environments; then AM G ArchSpec(AA). 
If Fg h ARCH-SPEC ^ AF then Fg h ARCH-SPEC > AF . 

Fg h BASIC-ARCH-SPEC ^ AF 



Fg h BASIC-ARCH-SPEC qua ARCH-SPEC ^ AF 
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ASN e Dom{As) 

(gs,Vs,As,Ts) h ASN qua ARCH-SPEC As(ASN) 

BASIC-ARCH-SPEC ::= basic-arch-spec UNIT-DECL-DEFN+ RESULT-UNIT 
UNIT-DECL-DEFN ::=UNIT-DECL I UNIT-DEFN 
RESULT-UNIT : := result-unit UNIT-EXPRESSION 



Fs h BASIC-ARCH-SPEC > AE T;;, h BASIC-ARCH-SPEC ^ AM 

Fs h BASIC-ARCH-SPEC AS 



Fs and F^ are compatible global environments; then AM G ArchSpec(Ad7). 
If Fg h BASIC-ARCH-SPEC AF then F^ h BASIC-ARCH-SPEO 

Fs h UNIT-DECL-DEFN+ C« 

Fs,Csh RESULT-UNIT UF 

Fs h basic-arch-spec UNIT-DECL-DEFN+ RESULT-UNIT {ctx{Cs),UF) 



Fs h UNIT-DECL-DEFN+ > Cg rs,F^ h UNIT-DECL-DEFN+ ^ C 

Fs b UNIT-DECL-DEFN+ C« 



Fs and Fm are compatible global environments; then C is compatible with Cg 
too. 

If Fs b UNIT-DECL-DEFN+ Cg then Fg b UNIT-DECL-DEFN+ t> Cg, with 

Cs = ctx(Cs). 



Fg,C^ b UNIT-DECL-DEFNi (Cs)i 

Fg, {Cg)n-1 b UNIT-DECL-DEFN„ (C,)„ 

Fg b UNIT-DECL-DEFNi . . . UNIT-DECL-DEFN„ {Cg)„ 



Fs,Cg\- UNIT-DECL-DEFN t> Fs,Fm,Cs,C \~ UNIT-DECL-DEFN ^ C 

Fg,Cs b UNIT-DECL-DEFN C' 



Fg and Fm are compatible global environments, and C is compatible with Cg; 
then C and Cg are compatible, Cg C C'g and C D C . 

C's extends Cg. 

UFg,Cs b UNIT-DECL-DEFN C' then Fg, ctx{Cg) b UNIT-DECL-DEFNt> 
and Cg = ctxiC'g). Moreover, if Fg,Fm, ctxiCg), C b UNIT-DECL-DEFN ^ C 
and C is compatible with Cg then C and C' are compatible. 

Fg,Cs^ UNIT-DECL C' 

Fs,Cs b UNIT-DECL qua UNIT-DECL-DEFN Cg + C'g 
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Fs.Cs h UNIT-DEFN C' 

A , C 5 h UNIT-DEFN qua UNIT-DECL-DEFN ^ C 5 + C' 



Fs.Cs^ RESULT-UNIT > UU A, (7^, C h RESULT-UNIT ^ UEv 

Es.Cs RESULT-UNIT ^ UE 



Eg and Em are compatible global environments, and (7 is a unit context that is 
compatible with static unit context Cg'^ then UE and UEv G UnitEval(t/i7) 
are compatible additions to Cg and C. 

If Eg.Cg h RESULT-UNIT ^ UE then Eg, ctx(Cg) h RESULT-UNIT > UE. 

Eg.Cg^ UNIT-EXPRESSION ^ (p, UE,D) 

Eg.Cg h result-unit UNIT-EXPRESSION^ UE 

5.6.3 Unit Declarations and Definitions 
Unit Declarations 

UNIT-DECL ::= unit-decl UNIT-NAME UNIT-SPEC UNIT-IMPORTED 

UNIT-IMPORTED : := unit -imported UNIT-TERM* 

UNIT-NAME ::= SIMPLE-ID 



Eg.Cg^ UNIT-DECL > A, (7^, (7 h UNIT-DECL ^ C 

Eg.Cg h UNIT-DECL C' 



Eg and Un are compatible global environments, and (7 is a unit context that 
is compatible with static unit context Cg'^ then (7j and C are compatible 
extensions of Cg and C. 

Cg is an admissible addition to Cg. 

If Eg.Cg h UNIT-DECL ^ C' then Eg,ctx{Cg) h UNIT-DECL > (7j, with 
Cg = ctx{Cg). Moreover, if Eg^ E^^ ctx{Cg)^ C h UNIT-DECL ^ C and C is 
compatible with Cg then C and Cg are compatible extensions of C and Cg. 

Cg h UNIT- IMPORTED ^ (p, D) 

D{p), Eg h UNIT-SPEC > i: 

UN 0 Dom{Cg) 

D' extends D by new node q with D'{q) = D{p) C E 

and edge e: p^q with D'{e) = iD(p)CD'(q) being the inclusion 

A, C 5 h unit-decl UN UNIT-SPEC UNIT- IMPORTED ^ 

{{},{UN^q},D') 
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Cs h UNIT- IMPORTED (p, D) 

D{p), Fs h UNIT-SPEC t> S^Eo 
UN ^ Dom{Cs) 

A, Cg h unit-deci UN UNIT-SPEC UNIT- IMPORTED 

{{UN ^ E^)},{},D) 



Cs h UNIT- IMPORTED > Cs,C^ UNIT- IMPORTED ^ MEv 

Cs h UNIT- IMPORTED ^ (p, D) 



(7 is a unit context that is compatible with static unit context Cs; then E 
and MEv are compatible additions to Cs and C. 

D extends dgm{Cs) and p G Nodes {D). 

If Cs 7 UNIT-IMPORTED (p,D) then ctx{Cs) 7 UNIT- IMPORTED > 
with E = D{p). Moreover, if ctx{Cs)^ C h UNIT- IMPORTED ^ MEv and C is 
compatible with Cs then (p, D) and MEv are compatible additions to C and 
C,. 



Cs UNIT-TERMi {pi,Di) • • • h UNIT-TERM/, {pk, Dk) 

E = Di{pi)C...CDk{pk) 

1 ^ 1 , , Dk disjointly extend dgm{Cs) D' = DiC . . .C Dk 
D' ensures amalgamability along (E, {iDi(pi)cu • ^ 

D" extends D' by new node q with D"{q) = E 

and edges : Pi^q with D"{ei) = iDi(pi)CE^ for z = 1, . . . , A; 

Cs 7 unit -imported UNIT-TERM^ , . . . , UNIT-TERM;, {q,D") 

Assuming that the extended static analysis is successful for the phrase 
unit -imported UNIT-TERM^ jUNIT-TERM;,, we can simplify the corre- 
sponding rule in the model semantics as follows: 

Cs, C h UNIT-TERMi ^ MEvi • • • Cs,C h UNIT-TERM^ ^ MEvk 
for each E c C, MEvi{E )^ . . . , MEvk{E) arc compatible 
Cs,C h unit -imported UNIT-TERM^ , . . . , UNIT-TERM;, ^ 

XE G C^MEvi{E) 0 ... 0 MEvk{E) 



Unit Definitions 

UNIT-DEFN ::= unit-defn UNIT-NAME UNIT-EXPRESSION 



Es,Cs^ UNIT-DEFN > C{ A, (7^, (7 h UNIT-DEFN ^ C 

Es,Cs h UNIT-DEFN C' 
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Fg and Fj^ are compatible global environments, and (7 is a unit context that 
is compatible with static unit context (7s ; then (7j and C are compatible 
extensions of Cg and (7, and moreover, C' maps any unit in its domain to a 
one-element set of unit evaluators. 

Cg is an admissible addition to Cg. 

If Fg,Cg h UNIT-DEFN ^ C' then Fg,ctx(Cg) h UNIT-DEFN > (7j, with 
Cg = ctx{Cg). Moreover, if Fg^ F^^ ctx{Cg)^ C h UNIT-DEFN ^ C and C is 
compatible with Cg then Cg and C are compatible extensions of C and Cg. 

Fg,Cg h UNIT-EXPRESSION ^ 

UN 0 Dom{Cg) 

h unit-defn UN UNIT-EXPRESSION ^ ({},{ /77V ^ p}, I}) 

Fg.Cgh UNIT-EXPRESSION ^ 

UN 0 Dom{Cg) 

Fg, Cg hunit-defn UN UNIT-EXPRESSION {{UN ^ {p,F^F)},{},D) 

5.6.4 Unit Specifications 

For unit specihcations, extended static semantics coincides with the static 
semantics above, so no new rules are needed. 



5.6.5 Unit Expressions 

UNIT-EXPRESSION : := unit -express ion UNIT-BINDING* UNIT-TERM 
UNIT-BINDING : := unit-binding UNIT-NAME UNIT-SPEC 



Fg.Cgh UNIT-EXPRESSION > UF 

Fg,Fm, Cg,Ch UNIT-EXPRESSION ^ UEv 
Fg.Cgh UNIT-EXPRESSION (p, UF, D) 



Fg and Un are compatible global environments, and (7 is a unit context that 
is compatible with static unit context Cg; then UF and UEv are compatible 
additions to Cg and (7. 

D extends dgm{Cg)^ p G Nodes {D). For UF = F ^ Sig, D{p) = F. For 
UF = F^F G ParUnitSig^ D{p) is the empty signature. 

If we have Fg,Cg h UNIT-EXPRESSION ^ (p,UF,D) then Fg,ctx{Cg) h 
UNIT-EXPRESSION > UF. Moreover, if we also have Eg, Fm, ctx{Cg), C h 
UNIT-EXPRESSION ^ UEv and C is compatible with Cg then UEv and 
(p, UF^D) are compatible additions to C and Cg. 

Fg,Cg^ UNIT-TERM ^ (p, D) 

Fg, Cg h unit-expression UNIT-TERM {p, D{p), D) 
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Fs h UNIT-BINDINGi {UN i, Si) ■■■ h UNIT-BINDING„ {UN„,S„) 

S = {Si, • • • , Sn) S = Si U . . . U Sn 
UNi , . . . , UNn are distinct { UNi , . . . , LW„} n Dom{Cs) = 0 
D' extends dgm{Cg) by new node q with D'{q) = S, 

nodes pi and edges e* : Pi^q with D'{ei) = LSiCS, for i = 1, . . . , n 
C{ = ({}, {UNi^pi,..., UNn ^ Pn], D') 

Ts, Cs + C' h UNIT-TERM {p, D”) 

D" ensures amalgamability along {D"{p), {idui/^pp iSiCD"(p))i=i,...,n) 

D'" extends D" by new node z with D"'{z) = 0 

FsjCs b 

unit-expression UNIT-BINDING^ , . . . ,UNIT-BINDING„ UNIT-TERM 

{z,S^D"{p),D"') 

Assuming that the extended static analysis is successful for the phrase 
unit-expression UNIT-BINDINGj , . . . ,UNIT-BINDING„ UNIT-TERM, we can 
simplify the corresponding rule in the model semantics as follows: 

Ug h UNIT-BINDINGi > {UN i, Si) ■■■ Ug^ UNIT-BINDING„ t> ( UN„,S„) 
rg,Um h UNIT-BINDINGi ^ {UNi,Mi) 

r,,r„ h UNIT-BINDING„ ^ {UNn,Mn) 

S^ = Si U . . . U Sn — Nil 0 • • • 0 Nin 

UN^ i Dom{Cg) yj {UN 1 , UNn) 

C{ = { UN^ ^ SP, UNi ^ Si,..., UNn ^ Sn} 

C' = C'^[UN’" IMP][UNi/{\E-E{UN^)\E,)]...[UNnl{\E-E{UN’")\s„)] 
Eg, Em, Cg U C'g, (7 n C" h UNIT-TERM 0- MEv 
for all .g c g n C, MEv{E) \ ^p ^ E{UN^) 

UEv e UnitEv8d(Z'i, . . . , Sn^S) is such that Dom{UEv) = C and 
for E e C, 

{Mi,...,M„)e Dom{ UEv{E)) C CompMod(A’i , . . . , S„) iS 
E + { UN^ (Ml © ... 0 Mn), UNi ^ Ml,..., UNn ^ M„} e C n C 
and then for {Mi, . . . ,Mn) G Dom{UEv{E)), 

UEv{E){Mi,...,M„) = 

MEv{E 0 { UN^ (Ml © ... © Mn), UNi ^ Mi,..., UNn ^ M„}) 
rg,rm,Cg,ch 

unit-expression UNIT-BINDING^ , . . . ,UNIT-BINDING„ UNIT-TERM 

^ UEv 



Fg h UNIT-BINDING t> ( UN, S) Eg, Em b UNIT-BINDING ^ ( UN, M) 

Eg b UNIT-BINDING ( UN, S) 
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Fg and Fj^ are compatible global environments; then UN is a unit name (the 
same for the static and model semantics) and Ai C Mod(i7). 

If Fs h UNIT-BINDING ^ ( UN, F) then Fg h UNIT-BINDING > ( UN, F). 

0, Fg h UNIT-SPEC ^ i: 

Fg h unit-binding UN UNIT-SPEC ^ {UN, F) 



Unit Terms 

UNIT-TERM ::= UNIT-REDUCTION | UNIT-TRANSLATION | AMALGAMATION 
I LOCAL-UNIT I UNIT-APPL 



Fg,Cgh UNIT-TERM > Fg,Fm,Cg,C h UNIT-TERM ^ MEv 

Fg,Cgh UNIT-TERM {p,D) 



Fg and Fj^ are compatible global environments; (7 is a unit context that 
is compatible with static unit context Cg; then F and MEv are compatible 
additions to Cg and C. 

D extends dgm{Cg), p G Nodes {D). 

If Fg,Cg h UNIT-TERM ^ (p,D) then Fg, ctx{Cg) h UNIT-TERM > with 
F = D{p). Moreover, if Fg,Fm, Cg,C ^ UNIT-TERM ^ MEv and C is com- 
patible with Cg then MEv and {p, F, D) are compatible additions to C and 
C,. 

Rules elided. 

Unit Translations 

UNIT-TRANSLATION : := unit-translation UNIT-TERM RENAMING 



Fg,Cgh UNIT-TRANSLATION > 

Fg,Fm,Cg,C h UNIT-TRANSLATION ^ MEv 
Fg,Cg h UNIT-TRANSLATION ^ {p, D) 



See the requirements for the semantics of UNIT-TERM. 

Fg,Cgh UNIT-TERM {p,D) 

D{p) h RENAMING > a:D{p)^F' 

D ensures amalgamability along {F' , {a:D{p)^F')) 

D' extends D by new node q and edge e: p^q with D'{e) = a 
Fg,Cg h unit-translation UNIT-TERM RENAMING^ {q,D') 
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Assuming that the extended static analysis is successful for the phrase 
unit -translation UNIT-TERM RENAMING, we can simplify the corresponding 
rule in the model semantics as follows: 

Fs.Csh UNIT-TERM > i: 
rs.Fjn.Cs.C h UNIT-TERM ^ MEv 
E h RENAMING > 

for all E C C ^ there exists a unique C Mod(i7^) with M' \ (j = MEv{E) 

Es.Em, Cs, C h unit -translation UNIT-TERM RENAMING ^ 

{E ^ M' \ E e C,M' e Mod{E'),M'\^ = MEv{E)} 

The semantics of RENAMING is given in Sect. 4.2.1. 

Unit Reductions 

UNIT-REDUCTION : := unit -reduct ion UNIT-TERM RESTRICTION 



Es.Cs^ UNIT-REDUCTION > i: (7^, C h UNIT-REDUCTION ^ MEv 

Fs.Cs UNIT-REDUCTION (p, T>) 



See the requirements for the semantics of UNIT-TERM. 

Es.Cs^ UNIT-TERM (p, D) 

(0, D{p)) h RESTRICTION > 

D' extends D by new node q and edge e: q^p with D\e) = tz!'CD(p) 

D' ensures amalgamability along {E" , {a: D'{q)^ E")) 

D" extends D' by new node q' and edge e: q^q' with D"{e) = a 
Fs, Cs h unit-reduction UNIT-TERM RESTRICTION ^ {q',D”) 

Assuming that the extended static analysis is successful for the phrase 
unit-reduction UNIT-TERM REDUCTION, we can simplify the corresponding 
rule in the model semantics as follows: 

Fs,Cs^ UNIT-TERM > 

Fs,Fm,Cs,C ^ UNIT-TERM ^ MEv 
(0, E) h REDUCTION > aiE'^E" 

for all E G C, 

there exists a unique M" C Mod(i7^^) with M'' \ cr = MEv{E) \ z;' 
Fs,Fm, Cs, C h unit-reduction UNIT-TERM RESTRICTION^ 

{Ee^ M" \ E e C,M" G mod{E"),M"\^ = MEv{E)\jj>} 

The semantics for RESTRICTION is given in Sect. 4.2.2. 
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Amalgamations 

AMALGAMATION : := amalgamation UNIT-TERM+ 



Fs, Cs h AMALGAMATION > A, (7^, C h AMALGAMATION ^ MEv 

Es.Cs^ AMALGAMATION ^ (p, D) 



See the requirements for the semantics of UNIT-TERM. 

Fs.Cs h UNIT-TERMi ^ (pi, A) • • • h UNIT-TERM^ (pn^Dn) 

E = Z^i(pi) U . . . U 

1 ^ 1 , ... , Dn disjointly extend dgm{Cs) D' = DiVJ . . .VJ 
D' ensures amalgamability along (E, {iDi(pi)CE • D'{pi) ^ 

D" extends D' by new node q with D"{q) = E 

and edges : Pi^q with D"{ei) = iDi(pi)CE^ z = 1, . . . , n 

Fs, Cs h amalgamation UNIT-TERM^, . . . , UNIT-TERM^ {q,D") 

Assuming that the extended static analysis is successful for the phrase 
amalgamation (UNIT-TERM^ , . . . , UNIT-TERM^) , we can simplify the corre- 
sponding rule in the model semantics as follows: 

Fs, Fm, Cs, C h UNIT-TERMi ^ MEvi 

Fs,Fm,Cs,C ^ UNIT-TERM^ ^ MEvn 
for all E c C, MEvi{E )^ . . . , MEvn{E) arc compatible 
Fs,Fm, Cs, C h amalgamation UNIT-TERM^ , . . . , UNIT-TERM^ ^ 

\E G C‘MEvi{E) 0 ... 0 MEvk{E) 



Local Units 

LOCAL-UNIT ::= local-unit UNIT-DEFN+ UNIT-TERM 



Fs,Cs^ LOCAL-UNIT > A Fs,Fm,Cs,C h LOCAL-UNIT ^ MEv 

Fs,Cs h LOCAL-UNIT^ (p,D) 



See the requirements for the semantics of UNIT-TERM. 

Fs,Cs hUNIT-DEFNi ^ (^5)1 

Fs,Cs 0 {Cs)l 0 ... 0 {Cs)n-1 ^ UNIT-DEFN^ ^ {Cs)n 
Fs,Cs 0 {Cs)i 0 ... 0 {Cs)n ^ UNIT-TERM ^ (p,D) 

Fs,Cs h local-unit UNIT-DEFNi , . . . ,UNIT-DEFN^ UNIT-TERM ^ (p,D) 
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Unit Applications 

UNIT-APPL ::= unit-appl UNIT-NAME FIT-ARG-UNIT* 
FIT-ARG-UNIT ::= f it-arg-unit UNIT-TERM SYMB- MAP -ITEMS* 



Us, Cs^ UNIT-APPL > i: Us.rm.Cs.C h UNIT-APPL ^ MEv 

Es.Cs^ UNIT-APPL ^ (j9, D) 



See the requirements for the semantics of UNIT-TERM. 

B,{UN)=p 

Fg, (Pg, Bg, D) h unit-appl UN Cg> (p, D) 

Cs = {Ps,Bs,D) 

= D{p^) yjEiVJ ...yjEn 

Ei,Ps,Cs h FiT-ARG-uNiTi i:>i) 

hFIT-ARG-UNITn {aniE^^E^ ,p^ , D^) 

1 ^ 1 , , Dk disjointly extend D U . . . U 

= D{p^) UE^U ...UE^ = {idnipi) U ai U . . . U an) : E^ ^ E^ 

a^{A) : E (E^ U i7^(Z\)), where AiE^^E is the signature extension 

E^ = E^UE^{A) 
ensures amalgamability along 

Ue(^(ZE^'' ^ P^^)i=l,...,n) 

D' extends by new node edge : p^ with D\e^) = Ld{p^)(iei 
nodes pf and edges ef : pf with D'{ef) = leiCE 
and Ci : pf ~^pf with D'{ei) = for z = 1 , . . . , n, 

D' ensures amalgamability along 

{E^,{a^{A): E^E^.i^A^^n: Ef^E^),=^_n) 

D" extends D' by new node g, edge e' : q^ ^q with D"(e') = a^{A) 
and edges e' : pf^q with D"{e[) = i^^dERi for z = 1, . . . , n 

A, C 5 h unit-appl UN FIT-ARG-UNITi , . . . ,FIT-ARG-UNIT^ ^ (g, I}") 

See Sect. 4.1.3 for the definition of a^(Z\), the extension of a signature mor- 
phism along a signature extension. 

Assuming that the extended static analysis is successful for the phrase 
unit-appl UN FIT-ARG-UNITi , . . . ,FIT-ARG-UNIT^, we can simplify the 
corresponding rule in the model semantics as in Fig. 5.1. 
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Cs{UN) = 

U EiU . . .U S„ 

El, r^, Cs I- FIT-ARG-UNITi > av.Ei^Ef 
El, Es, Fm, Gs, C h FIT-ARG-UNITi => MEvi 

Eu, Fs, Cs h FIT-ARG-UNITn > a„:En^E^ 
En,F„Fm,Cs,C FIT-ARG-UNITn => MEVn 
for all E e C , {MEvi{E)\^^, . . . , MEvn{E)\^„) e Dom(E(UN)) 

E^ = E^ \jEtyJ ...yjE^ = {idsi yj (JilJ . . .U <Ju)- E^ ^ E^ 

a^(A) : E {E^ U E^{A)), where A:E^^E is the signature extension 

for all E e C, there exists a unique M e Mod(r^ U E^(A)) 
ouch that M \ ^a = MEvi{E), . . . , M \ ^a = MEv„{E) and 

= E{UN){MEvi{E%„. . . , MEvn{E) \ ^„) 

MEv = {E^M I Ee C,M eModiE'^UE^ (A)), 

= E{ UN){MEvi{E)\„, MEvn{E)\^„), 
M\^a = MEvi(E),...,M\sa = MEvn(,E)} 



unit-appi UN FIT-ARG-UNITi , . . . , FIT-ARG-UNITn ^ MSt) 
Fig. 5.1. Simplified model semantics rule for unit applications 



Note also that the verihcation of the condition 

for all E G C,{MEvi{E)\^^,...,MEvn{E%^) G Dom{E{UN)) 

may be somewhat simplihed here - the extended static analysis ensures the 
compatibility of the actual parameters with the imports (implicitly required 
here) used to dehne the generic unit. 



i:, Es.Cs^ FIT-ARG-UNIT > 

S,rs,Fyn,Cs,C V- FIT-ARG-UNIT ^ MEv^ 
E,Fs,Cs h FIT-ARG-UNIT t:^ {a:S^S^,p, D) 



Eg and Ej^ are compatible global environments; (7 is a unit context that 
is compatible with static unit context Cg] then a: E ^ is a signature 
morphism, and E^ and MEv^ are compatible additions to Cg and C . 

D extends dgmiCg)^ p G Nodes {D)^ and D{p) = E^. 

If E,Eg,Cg h FIT-ARG-UNIT ^ {a:E^E^,p,D) then E,Eg,ctx{Cg) h 
FIT-ARG-UNIT Moreover, liE^Eg^Em, Cg, C h FIT-ARG-UNIT^ 
MEv^ and C is compatible with Cg then MEv^ and (p, E^, D) are compatible 
additions to C and Cg. 
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UNIT-TERM (p, D) 

I- SYMB-MAP- ITEMS* > r 

U.Fs.Cs h f it-arg-unit UNIT-TERM SYMB-MAP- ITEMS* ^ 

See Sect. 4.1.3 for the definition of the signature morphism 

induced by the symbol map r. 

The semantics of SYMB-MAP- ITEMS* is given in Sect. 4.5.2. 



5.6.6 Discussion 

The requirements stated above on the semantic judgements for each syntactic 
category provide the kernel of an inductive proof of the correctness of the 
extended static semantics: if the extended static semantics is successful then 
the simple static semantics of the previous sections is successful as well and 
yields corresponding results. Moreover, the requirements stated there justify 
the simplifications of the model semantics indicated above, given that the 
extended static semantics has been successful. 

Of course, no completeness result can be expected: even when the simple 
static semantics and the model semantics are successful for a given phrase, 
the extended static semantics may fail: it additionally requires that the amal- 
gamability conditions must be discharged on the basis of the information on 
sharing between symbols as stored in the signature diagram in the extended 
static context. This is stricter than the simple static and model semantics in 
two respects. First, the requirements imposed on units by their specifications 
are disregarded, and so symbols may be viewed as distinct even if these spec- 
ifications ensure that they always have the same interpretation. Second, in 
order for two symbols to share here they must be traced to the same sym- 
bol in some (non-generic) unit declaration or definition. This implies that the 
symbols in the result of application of a generic unit to an argument share 
with the environment only via the argument (and the imports, if any). In 
particular, new symbols in the results of two applications of a generic unit 
do not share, even if the arguments coincide. This gives a so-called generative 
semantics of generic modules, and the corresponding generative type disci- 
pline is often adopted for module systems of programming languages (e.g.. 
Standard ML, cf. [26]). 

The generative and applieative (non-generative) semantics coincide if ev- 
ery generic unit is used at most once. For any architectural specification 
ARCH- SPEC, one can build its generative version ARCH- SPEC as follows. For 
each generic unit F declared in ARCH -SPEC, let np be the number of applica- 
tions of F used in unit terms in ARCH- SPEC, li np > 1 then we replace the 
declaration of F by declarations oinp new units with distinct names and the 
same specification as F, and replace each application of F by a single appli- 
cation of one of the new units. Now, the (applicative) semantics of ARCH- SPEC 
gives a generative semantics for ARCH -SPEC. 
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Then, let |ARCH-SPEC| result from ARCH-SPEC by removing all the axioms in 
all the specihcations involved, so that all the specihcations used in ARCH- SPEC 
are reduced to signatures in |ARCH-SPEC|. (This is very informal, but hopefully 
intuitively quite clear: a precise dehnition would have to go recursively through 
the specihcation as well as through the global environments it relies on.) 

If the simple static semantics and model semantics are successful for both 
ARCH^EC and |ARCH^EC|, and neither ARCH^EC nor |ARCH^EC| involves 
generic units with inconsistent specihcations, then the extended static seman- 
tics and modihed model semantics are successful on ARCH-SPEC as well and the 
results of the simple and extended semantics for ARCH -SPEC match. The key to 
this property is the fact that if axioms are removed from specihcations then 
for any syntactic phrase, given the signature diagram and the unit context 
constructed for it, any model family that is compatible with this signature 
diagram may be obtained for a unit environment that hts the unit context. 
Then, by dehnition, the extra amalgamability requirements imposed by the 
extended static semantics coincide with the requirements eliminated from the 
original model semantics. See Chap. IV:5 for more details. 




6 



Specification Library Semantics 



A local library in Casl is a named sequence of definitions, each of which names 
a (structured, generic, view, architectural, or unit) specification. The (static 
and model) semantics of such a definition compute extensions of given global 
environments, as defined in Chaps. 4 and 5. The semantics of a library consists 
of the name of the library, together with the global environment obtained by 
composing the extensions given by the semantics of its definitions, starting 
from the empty global environment. 

Casl supports the installation of distributed libraries on the Internet, also 
allowing different versions of the same library. A library can either be identified 
by a URL that gives direct access to (all existing versions of) the library, or it 
can be registered with a hierarchical path name in a global directory, giving 
indirect access. In both cases, there may be more than one URL giving access 
to the same library (due to mirrors, caches, and redirections). 

A so-called downloading item in a library refers to particular definitions 
that are supposed to be provided by a different library. The semantics of the 
downloading item extends the global environment (of the enclosing library) 
with part of the global environment given by the semantics of the referenced 
library (possibly providing different names for the downloaded items, e.g. to 
avoid clashes with names already in use in the enclosing library). A reference to 
another library can either specify a particular version, or leave the version open 
(in which case the version that has the largest version number is obtained). 
Downloading must not lead to cyclic chains of references. 

The rest of this chapter gives a formal semantics for specification libraries, 
extending what was provided for basic, structured, and architectural speci- 
fications in Chaps. 2-5. Section 6.1 defines some semantic domains: global 
environments and directories, and universal environments. Section 6.2 defines 
the semantics of local libraries, and Sect. 6.3 extends the semantics to cover 
the downloadings used in distributed libraries. Finally, Sect. 6.4 deals with 
library names and versions. 
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6.1 Library Concepts 



Specifications may be named by definitions and collected in libraries. In 
the context of a library, the (re) use of a specihcation may be replaced by 
a referenee to it through its name. The current association between names 
and the specihcations that they reference is called the global environment'^ 
the global environment for a named specihcation is determined exclusively 
by the dehnitions that precede it. 



A statie global environment Fg = {Qs^Vg, Ag^Fg) consists of hnite func- 
tions from names to the static denotations of generic specihcations, views, 
architectural specihcations and unit specihcations: 

• Qg : SpeeName ^ GenSig 

• Vs : View Name ^ ViewSig 

• Ag : ArehSpeeName ^ ArehSig 

• Tg : UnitSpeeName ^ UnitSig 

Similarly, a model global environment Fm = Vm, -4^, consists of 
hnite functions from names to the model denotations of generic specihcations, 
views, architectural specihcations and unit specihcations: 

• Sm • SpeeName ^ GenSpec 

• Vm • ViewName ^ View'Spec 

• Am • ArehSpeeName ^ ArchSpec 

• %n : UnitSpeeName ^ Unit Spec 

The domains of the various components of static and model global environ- 
ments are disjoint. 

The semantic domains GenSig^ GenSpec, ViewSig^ View'Spec are de- 
hned in Chap. 4, while ArehSpeeSig ^ ArchSpec, UnitSpeeSig and UnitSpec 
are dehned in Chap. 5. 

A static global environment Fg = {Qg^Vg, Ag^Tg) and a model global 
environment Fm = {SrmVm^ Am^%n) are eompatible if for each compo- 
nent F of the global environment {F G {0,V,A, T}) and for each name 
Name G SIMPLE- ID either its static and model denotations are compatible, 
that is, Fg{Name) and Fm{Name) are compatible, or both Fg{Name) and 
Fm{Name) are undehned. Compatibility of static and model semantics is de- 
hned in the respective sections of Chaps. 4 and 5. 

IN G ItemName = SpeeName = ViewName = 

ArehSpeeName = UnitSpeeName = SIMPLE- ID 
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A library may be located at a particular site on the Internet. The library 
is referenced from other sites by a name which determines the location and 
perhaps identihes a particular version of the library. To allow libraries to 
be relocated without this invalidating existing references to them, library 
names may be interpreted relative to a global directory that maps names 
to URLs. Libraries may also be referenced directly by their (relative or ab- 
solute) URLs, independently of their registration in the global directory. A 
library may incorporate the downloading of (the semantics of) named speci- 
hcations from (perhaps particular versions of) other libraries, whenever the 
library is used. 



The semantics of libraries involves URLs^ paths^ and version numbers: 

u G Url 
p G Path 

V G Version = FinSeq{Nat) 

The internal structure of Url and Path is irrelevant in the semantics. Version 
numbers are ordered lexicographically: (rzi , . . . ^Uj) < {n[^ . . . , iff either 

• there exists i < j^k such that Ui < n[ and for alH < z, rz/ = nj, or 

• j < k and for all I < j, rz/ = n[. 

A (canonical) library name LN is a library identiher LI (i.e. a URL or a 
path) together with a (possibly empty) version: 

LI G Libid = Url i±) Path 
LN G LibName = Libid x Version 



The empty version () may only be used to name a library that exists in 
just one version: if a second version of the same library is installed, the two 
versions must both be distinguished by non-empty version numbers. (This is 
the only case where an already-installed version of a library can be given a 
new version number.) However, () may always be used to refer to the version 
of a library that has the largest version number. 



A static universal environment Ug is a hnite function from URLs and 
versions to static global environments: 

Ug G UnivEnVg = Url x Version ^ GlobalEnVg 

such that for all u G Url^ when v is the largest version number with (rz, u) G 
Dom(Ug)^ we have Ug(u^ ()) = Ug(u^v). 

Similarly, a model universal environment U^ is a hnite function from URLs 
and versions to model global environments: 

Ujn G UnivEnVjn = Url x Version ^ GlobalEnVm 
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such that for all u G Url^ when v is the largest version number with (u, v) G 
Dom{Um), we have Um{u,{)) = Um{u,v). 

A global directory GD is a hnite function from paths and versions to URLs: 

GD G GlobalDir = Path x Version ^ Url 

such that for all p G Path^ when v is the largest version number with (p, v) G 
Dom{GD)^ we have GD{p^ ()) = GD{p^v). 

Us^ Urm and GD are compatible iff: 

• Dom{Us) = Dom{Ujn)i 

• for all (u, u) G Dom(Us)^ the global environments Us(u^v) and Um(u^v) 
are compatible, as dehned above; and 

• for all (p,u) G Dom{GD)^ {GD{p,v),v) G Dom{Us). 



6.2 Local Libraries 

LIB-DEFN ::= lib-defn LIB-NAME LIB-ITEM* 

LIB-ITEM ::= SPEC-DEFN | VIEW-DEFN | ARCH-SPEC-DEFN | UNIT-SPEC-DEFN 

A library dehnition LIB-DEFN provides a collection of specihcation (and per- 
haps also view) dehnitions. It is well- formed only when the dehned names 
are distinct, and not referenced until (strictly) after their dehnitions. The 
global environment for each dehnition is that determined by the preceding 
dehnitions. Thus a library in Casl provides linear visibility, and mutual or 
cyclic chains of references are not allowed. 



The semantics of distributed libraries in the next section involves universal 
environments U 5 , Um that map URLs and versions to global environments, 
as well as a global directory GD that maps paths and versions to URLs, as 
dehned in Sect. 6.1. These components are incorporated but ignored by the 
semantics of local library items. 

The effect of processing a library dehnition may depend not only on U 5 , 
Urm and GD^ but also on the URL at which the library is to be located (and 
possibly registered). The details of library installation and registration are out 
of the scope of this semantics. 



Us, GD h LIB-DEFN > (LA, Ps) Us, Um, GD h LIB-DEFN ^ (LA, Pm) 

Us, Um, and GD are required to be compatible. Ps and Pm are then compatible 
too. 



h LIB-NAME > LA versionOK {Us, GD, LN) 

Us, GD, 0 h LIB-ITEM* > Tj 
Us, GD h lib-defn LIB-NAME LIB-ITEM* > {LN , P^) 
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where for all u G Url^v G Version^ versionOK{Us, GD, (u^v)) means 

V = {) implies {v^ \ {u^v') G Dom{Us)} = {()} 

and for all p G Path^v G Version^ versionOK{Us, GD, (p,'^)) means 

V = {) implies {v' \ {p^v') G Dom{GD)} = {()} 

h LIB-NAME > LN versionOK(Um, GD, LN) 

Us,Um, GD, 0, 0 h LIB- ITEM* ^ P^ 

Us, Um, GD h lib-defn LIB-NAME LIB-ITEM* ^ (LTV, P^) 
where for all u G Url^v G Version^ versionOK{Um, GD, (u,v)) means 

V = {) implies {v' \ {u,v') G Dom{Um)} = {()} 

and for all p G Path,v G Version, versionOK (Um, GD, {p,v)) means 

V = {) implies {P \ {p,P) G Dom{GD)} = {()} 



Us, GD, Ps h LIB-ITEM > P'^ 



Us, U^, GD, Ps, Pm ^ LIB-ITEM ^ P^ 



Us, Ujn, and GD are required to be compatible; so are Ps and Pm. Then Tj 
and P^ are compatible, and extend Ps, resp. Pjn- 

Ps h SPEC-DEFN > Tj 

Us, GD, Ps h SPEC-DEFN qua LIB-ITEM > P’^ 

A, h SPEC-DEFN ^ r;;, 

Us,Um, GD,rs,Pm ^ SPEC-DEFN qua LIB- ITEM ^ 

Similar rules for VIEW-DEFN, ARCH-SPEC-DEFN, and UNIT-SPEC-DEFN are 
elided. The semantics of SPEC-DEFN and VIEW-DEFN is dehned in Chap, 4, and 
the semantics of ARCH-SPEC-DEFN and UNIT-SPEC-DEFN is dehned in Chap, 5. 



Us, GD,Ps h LIB-ITEM* > P'^ Us,Um, GD,rs,Pm ^ LIB-ITEM* ^ P'^ 

Us, Um, and GD are required to be compatible; so are Ps and Pjn- Then Tj 
and are compatible, and extend Ps, resp. Pm. 

Us, GD, {Ps)o h LIB-ITEMi > (r,)i 

Us, GD, {Ps)n-1 ^ LIB-ITEMn > {Ps)n 



Us,GD,{Ps)o^LlB-li:Eni ... LIB-ITEM^ > (r^)^ 
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U„ GD, (r,)o h LIB-ITEMi > (r,)i 

Us, Ura, gd, (r,)o, (r„)o h LiB-iTEMi ^ (r„)i 

Us, GD, h LIB-ITEM„ > (r,)„ 

Us, Um, GD, (r,)„-i, (r^)n-i h LIB-ITEM„ ^ (r^)„ 

Us, Um, GD, {Ds)o, (r„)o h LIB-ITEMi . . . LIB-ITEM„ ^ (r„)„ 



6.3 Distributed Libraries 

LIB-ITEM ::= ... I DOWNLOAD- ITEMS 

DOWNLOAD- ITEMS : := download-items LIB-NAME ITEM-NAME-OR-MAP+ 

ITEM-NAME-OR-MAP : := ITEM-NAME I ITEM-NAME-MAP 

ITEM-NAME-MAP ::= item-name-map ITEM-NAME ITEM-NAME 

ITEM-NAME ::= SIMPLE-ID 

The ITEM-NAME-OR-MAP in a DOWNLOAD- ITEMS determines a selection and 
possible renaming of definitions from the named library, resulting in a global 
environment to be added to the current global environment. The following 
rules complete the definition of the semantics of library items, initiated in 
Sect. 6.2. 



h LIB-NAME > (u, v) {u, v) e Dom{Us) 

Us{u,v) ITEM-NAME-OR-MAP+> rj 
Us, GD,Ds h download- items LIB-NAME ITEM-NAME-OR-MAP+ t> T;, U 

h LIB-NAME t> (p, u) {p,v) & Dom{GD) {GD{p,v),v) £ Dom{Us) 
Us{GD{p,v),v) h ITEM-NAME-OR-MAP+ > 

Us, GD,Ds h download- items LIB-NAME ITEM-NAME-OR-MAP+ t> T;, U 
The rules for the model semantics are elided. 



Ds b ITEM-NAME-OR-MAP t> Dm b ITEM-NAME-OR-MAP ^ 



Dg — {Qs,Vs, As,Ds) IN G Dom(Qs) 

Ds b IN qua ITEM-NAME-OR-MAP t> {{IN ^ gs{IN)}, 0, 0, 0) 

Gs = (Qs,Vs,As,'Ts) INi£Dom{Qs) 

Ds b item-name-map INi IN 2 t> {{IN 2 ^ 0, 0, 0) 

The rules for the model semantics of ITEM-NAME-OR-MAP are elided, as are 
those for item names which refer to views, architectural specifications, and 
unit specifications. 
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Fs h ITEM-NAME-OR-MAP+ > F' Fm ITEM-NAME-OR-MAP+ ^ F'^ 

Fg and F!^ correspond to subsets of Fg^ resp. except that some of the 
item names may have been replaced. 

Fs h ITEM-NAME-OR-MAPi > {F^)i 
Fg h ITEM-NAME-OR-MAP^ > {F^)n 

Fg h ITEM-NAME-OR-MAPi . . . ITEM-NAME-OR-MAP^ > {F^)i U • • • U {F^)n 
The rules for the model semantics of ITEM-NAME- 0R-MAP+ are elided. 



6.4 Library Names 

LIB-NAME ::= LIB-ID | LIB-VERSION 

LIB-VERSION ::= lib-version LIB-ID VERS I ON -NUMBER 

VERSION-NUMBER ::= version-number NUMBER+ 

LIB-ID ::= DIRECT-LINK | INDIRECT-LINK 

DIRECT-LINK : := direct-link URL 
INDIRECT-LINK : := indirect-link PATH 

The following judgements provide canonical library names. 



h LIB-NAME > LN 

h LIB-ID > LI 
h LIB-ID qua LIB-NAME 

h LIB- ID t> LI h VERSION-NUMBER t> v 

h lib-version LIB-ID VERS I ON- NUMBER > {LI,v) 

h VERSION-NUMBER[> V 

w is a non-empty sequence of natural numbers. 

NUMBERj is decimal notation for rii, i = 1, ... ,m 
h version-number NUMBERi . . . NUMBER^ t> (ni, . . . , rim) 



h LIB-ID > L7 



h direct-link ut>u 



h indirect-link pt>p 
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Introduction 



This part of the Casl Reference Manual provides proof calculi for the various 
levels of Casl specihcations. It should be read together with the the Casl 
semantics (Part III). 

The aim of the Casl proof calculus is to support the users of Casl in the 
proof activities necessary in the process of software specihcation and develop- 
ment. Essentially, the goals are threefold. First, in a number of situations the 
model semantics for a Casl specihcation may fail even if the static semantics 
succeeds. This is the case for instance when a generic specihcation is instanti- 
ated with an actual parameter (which must then entail the formal parameter 
specihcation), when a view between two specihcations is formed, or when a 
generic unit is applied to an argument in an architectural specihcation. One 
aim of the calculi developed here is to (make explicit and help the user to) 
discharge proof obligations such situations imply. Once this is done, we can 
be sure that the specihcation in question denotes a class of models. Then, 
the second aim of the calculi developed here is to prove consequences of such 
specihcations - formulas that hold in all the models. Finally, this can be used 
to prove various relationships between Casl specihcations. 

This program is carried through the various layers of Casl. For basic spec- 
ihcations, no proof obligations arise, and proving their consequences amounts 
to proving consequences of a set of logical formulas. The corresponding calcu- 
lus for the logic of Casl is given in Chap. 2. Actually, the calculus is for the 
many-sorted sublanguage of Casl, but via the reduction of subsorted Casl 
to many-sorted Casl given in the semantics (Chap. III:3), it can also be used 
for subsorted Casl, see Chap. 3. 

Structured specihcations are treated in Chap. 4. Since Casl structured 
specihcations are quite complex, a simpler core formalism, called develop- 
ment graphs^ is introduced. A development graph consists of a set of nodes 
(corresponding to whole structured specihcations or parts thereof), and a set 
of arrows called dehnition links, indicating the dependency of each involved 
structured specihcation on its subparts. The proof calculus is given for devel- 
opment graphs, which makes the calculus much simpler than a calculus that 
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would directly act on Casl structured specifications. The proof calculus makes 
use of the calculus for basic specifications. The link between Casl structured 
specifications and development graphs is given by a verification semantics. It 
is similar to the static semantics of structured specifications, but simultane- 
ously extracts a development graph and a set of proof obligations (the latter 
are called theorem links). The proof obligations arise e.g. from instantiations 
of generic specifications. Once they have been extracted, they can be tack- 
led with the proof calculus. Indeed, the proof obligations can be discharged 
if and only if the model semantics of the structured specification under con- 
sideration succeeds. The proof calculus can also be used to prove intended 
consequences of structured specifications or check their consistency. In fact, 
for this purpose, there are Casl annotations such as %implies and %cons, 
and the verification semantics leads to appropriate further proof obligations 
(i.e. going beyond those capturing the model semantics). 

For the sake of simplicity, only a sublanguage of architectural specifications 
is covered in Chap. 5. The sublanguage is introduced with syntax, (extended) 
static and model semantics. The relation between extended static and model 
semantics is studied, continuing the discussion in Sect. 111:5.6.6. Based on the 
calculus for structured specifications, a calculus is developed that can be used 
for proving that a given architectural specification has a denotation w.r.t. its 
model semantics (i.e., is correct) and that the units produced using it satisfy 
a given unit specification. 

Finally, Chap. 6 points out how the various calculi may be integrated in 
order to obtain a calculus for proving the correctness of whole libraries. 



1.1 Institution Independence 

The proof calculi for structured and architectural specifications and libraries 
are independent of the framework that is used for basic specifications (this is 
similar to the institution independence discussed in Sect. 111:4.1). The seman- 
tics of basic specification defines an institution [20] , while the proof calculus 
for basic specifications extends this to a logic [34] (which is an institution 
equipped with a proof theoretic entailment relation). Hence, the proof cal- 
culi for structured and architectural specifications are parametrized over an 
arbitrary logic. The logic is required to fulfill some mild technical conditions. 

The actual subdivision between institution dependent and institution in- 
dependent calculi is not quite as clean as stated above. Namely, despite the 
fact that the calculus for structured specifications is institution independent 
in general, at some points, institution dependent proof rules are needed. This 
is due to the need to deal with free specifications and with checks for conser- 
vativity of extensions^. Up to now, these two problems have not been treated 

^ Note that checks for conservativity of extensions not only arise from explicit 
conservativity annotations; they may also arise during a proof of a proof obligation 
generated by a view whose source involves hiding. 
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in a logic independent way, and such a treatment seems to be rather difficult. 
Hence, one needs logic-specific rules at these places (see Sect. 4.6). 



1.2 Style of the Proof Calculi 

The proof calculi follow a natural deduction style. This makes the rules com- 
pact and easy to read. However, in the calculus for basic specifications, side 
conditions such as Eigenvariable conditions are not so easy to understand, 
compared to a Gentzen style presentation. We therefore indicate at some 
places how a Gentzen style presentation would look. 



1.3 Soundness and Completeness 

We prove the soundness of all the calculi for the different layers of Gasl, which 
shows that only logical consequences can be proved. The converse property, 
that all logical consequences can be proved, is known as completeness. Un- 
fortunately, the presented calculi are not complete, and they cannot be so in 
principle. There are different sources of incompleteness: 

• sort generation constraints in Gasl basic specifications, 

• Gasl structured specifications involving hiding and freeness (the former 
need some form of check for conservativity of extensions), and 

• consistency checks in Gasl architectural specifications. 

For these constructs of Gasl, there cannot be a recursively axiomatized com- 
plete calculus. However, we prove relative completeness results in the sense 
that if these constructs are omitted or if there is an oracle that deals with 
them, we obtain a complete calculus. Even then, completeness of the logic 
independent proof calculus for structured and architectural specifications of 
course requires completeness of the proof calculus of the logic for basic speci- 
fications. 
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Basic Specification Calculus 



Here, we define a proof calculus for many-sorted basic specifications as in- 
troduced in Chap. 1:2. In Chap. 3 below, also subsorted specifications are 
treated. 

The semantics of a basic specification is a signature together with a set of 
axioms; see Chap. Ill: 2. The proof calculus for basic specifications allows for 
deriving consequences from such a set of sentences. More specifically, the proof 
calculus is given by a set of rules, which together generate a proof-theoretic 
entailment relation. The proof calculus is shown to be sound, i.e. only logical 
consequences can be derived in the calculus. The converse, completeness, can- 
not be achieved due to the presence of sort generation constraints; however, 
the calculus is complete if the latter are omitted. 

Before we present the proof calculus, a few remarks on the syntax of for- 
mulas as defined in Sect. 111:2.1.3 are in order. As stated there, we restrict 
ourselves to a kernel language consisting of predicate applications, existen- 
tial equations, false, implication, and universal quantification - all the other 
types of equations, connectives and quantifiers can be expressed in terms of 
these. Moreover, we follow the remark stated there that it is possible to omit 
conditional terms of the form (p ^ these can be eliminated as described 
in Sect. 1:2. 5. 4 of the Casl Summary. Finally, for the sake of readability, we 
will deviate from the notation for formulas that has been introduced in the 
semantics of many-sorted basic specifications: within quantifications, instead 
of yxg.p we write \/x:s and we omit the sorts of variables and profiles of 
function and predicate symbols, if these are clear from the context. 

We now introduce some auxiliary notions about substitutions that are 
needed in the calculus rules. In the sequel, fix a many-sorted signature E = 
(5, TF,PF,P). 

Given an /S-sorted variable systems X, the /S-sorted set of X-terms over 
X is denoted by Tjj[X). 

Definition 2.1. Given an S -sorted variable systems X and Y, an S -sorted 
funetion u: X is ealled a substitution. Given a substitution u: X^ 




280 IV:2 Basic Specification Calculus 



TjjiY) and an S -sorted variable system Z, we denote by n \ Z : X U Z ^ 
TjjiY U Z) the substitution being the identity on Z and being n on X\Z . 

We now come to the definition of what it means to apply a substitution to 
a term or a formula. The application of a substitution to a formula is not 
dehned in all cases because of the variable capture problem: if a term that is 
substituted for a variable contains free variables, the latter must not newly 
get into the scope of a quantiher in the term or formula resulting from the 
substitution. 



Definition 2.2. The term t[z/] G Tjj{Y) resulting from applying the substitu- 
tion n to a term t G Tjj{X) is defined by 

• x[n] = ns{x) for x ^ Xg 

• fwsih, ■ ■ -,tn)W] = fws{ti[iy], ■ ■ -VnW]) 



Given a S -formula tp over X, the formula p[v], which is either undefined 
or a X -formula over Y resulting from applying the substitution u to p, is 
defined induetively over cp: 









{ti=t2)[n] = ti[iy]=t2[n] 

p^{ti,...fin)W] = 

false[n] = false 

{if fi)[u] = {p[iy]) => 

\/z:s' . {if[u \ if for all x ^ Xg, s ^ S', 

x[n] 7 ^ X and x G FV (Vz :s' .cp) 
imply z 0 FV{x[n]) 

I undefined^ otherwise 



{\fz:sT(p)[iy] = I 



The last case causes (Vz : s' .(p) [n] to be undehned if a name clash occurs 
(where a name clash means that a free variable in x[n] becomes bound by 
the quantihcation over Zgf). This restriction is important to keep the intended 
semantics of substitutions. 

The rules of derivation are given in Fig. 2.1 (the hrst-order rules) and 
Fig. 2.2 (the induction rules). They are given in a natural deduction style. 
Some rules such as (^-intro) need local assumptions, which means that 
their premises are of the form ‘if ip can be derived from (here, p> is the local 

[^] 

assumption). In the calculus, this is written : . 

The rule (Congruence) captures the usual congruence (take n{xg) to be 
a variable) as well as symmetry and transitivity of existential equality. 

Recall from Sect. 111:2.1.3 that D{t) abbreviates t = t^ and (pAip is dehned 
as a complicated term using ^ and false. For simplicity, we here consider 
(A^=i ^Pi) ^ diS an abbreviation for cpi ^ ... ^ <Pn ^ with ^ 
grouping to the right. 

For the induction rules (Fig. 2.2), without loss of generality we assume 
that for a sort generation constraint 
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[if => false] 



(Absurdity) 



false 



(Tertium non datur) 



(^-intro) 



(f ^ 






(f ^ f) 



(V-elim) 



(V-intro) ^ where Xs occurs freely only in local assumptions 



(Refiexivity) 



if Xs is a variable 



Us — 



(Congruence) 



(/\xseFV(cp) “ f{Xs)) ^ ^[f] 



if (f[u] defined 



(Totality) 



D{U,,{x,„... ,x,J) •■■««./ eTF^.s 



je- 



(Substitution) 

if (f[u] defined and FV{(p) occur freely only in local assumptions 



(Function Strictness) 



tl = t2 
D{t) 



t some subterm of ti or t 2 



(Predicate Strictness) — i G {1, . . . , n} 



Fig. 2.1. First-order deduction rules for Casl basic specifications 



(S',F',e: 

all the result sorts of function symbols in F' occur in S' . If not, we can just 
leave out from F' those function symbols not satisfying this requirement. The 
satisfaction of the sort generation constraint in any model will not be affected 
by this: in the ^-term t that (jointly with an appropriate assignment of its 
variables) witnesses the satisfaction of the constraint, any application of a 
function symbol with result sort outside S' can just be replaced by a variable 
of that sort, which then gets the value of the function application as assigned 
value. 

A derivation of ^ \~ (p is a tree (called derivation tree) such that 

• the root of the tree is 

• all the leaves of the tree are either in ^ or marked as local assumption. 
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{S',F',6: E^E) 

(Induction) 

Asgg, V® : 6>(s) . F,{x) 

F' = {/i: si ^s^; . . . ; fk'. sj . . . s^^ ^ s'=}, 

Ws is a formula with one free variable of sort ^(s), for s G S' ^ 

(fij = ~ixx : e(s{), ■■ ■ 

(D{e{fj){xi,. ,.,X,nj))A 4eS' '^4 (*<)) 

^ ^Sj {^{fj){xi,...,Xrrij)) 

(Sortgen-intro) A ■ ■ ■ A ^ : 6 {s) . p.jx) 

{S',F',6-. E^E) 

F' = {h-. ...; A: si...s!),,^s'=}, 

the predicates ps 0{s) {s G S') occur only in local assumptions, 
= Vxi : 9{s{), . . ..Xruj : • 

{p{e{fj){xi,. ..,XmP)^ A,6{i.^^..™ 4 eS' P 4 (2^0) 

^ Psj {9{fj){xi, . . . , Xrrij)) 

Fig. 2.2. Induction rules for Casl basic specifications 



• each non-leaf node is the (instance of the) conclusion of some rule, with 
its children being the (instances of the) premises, 

• all assumptions marked with [. . .] in the proof rules are marked as local 
assumptions. 

If ^ and if consist of i7-formulas, we also write ^ hx- f- In practice, one 
will work with acyclic graphs instead of trees, since this allows the re-use of 
lemmas. 

Some rules contain a condition that some variables occur freely only in 
local assumptions. These conditions are the usual Eigenvariable conditions of 
natural deduction style calculi. More precisely, they mean that if the men- 
tioned variables occur freely in an assumption in a proof tree, the assumption 
must be marked as local and have been used in the proof of the premise of 
the respective rule (that is, it must not be an undischarged assumption that 
gets discharged only by a different rule). 

Some readers might prefer a Gentzen-style presentation of the calculus, 
since this makes the role of the local assumptions and the Eigenvariable con- 
ditions more explicit. In order to help clarifications, we reformulate two of the 
rules in Gentzen style here: 



(^-intro) 



^ U {f} h 'ip 



^ \- f ^ ip 
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(Substitution) 



^\- (f 

^ ^ i/\xseFV(cp) ^ ^[f] 



if (f[iy] is defined and the free variables of (p do not occur freely in 

We now come to soundness and completeness of the calculus, largely fol- 
lowing the presentation in [9]. We present only the (easier) soundness proof, 
in order to allow the reader to get familiar with the rules. The completeness 
proof (for the hrst-order fragment) is more complex, but follows the standard 
techniques for hrst-order completeness proofs; hence, we do not repeat it here. 
We say that a i7-sentence p semantically follows from a set of i7-sentences 
written ^ 9^, if each i7-model satisfying all sentences in ^ also satis- 

hes p. 



Theorem 2.3. The calculus is sound i.e. 



T> T 'll T 

Moreover, the calculus is complete if sort generation constraints are not used, 



p only if \-jj p 
if^, p do not contain sort generation constraints. 

Proof. (Soundness) By induction over the proof tree construction, we show: 
for all signatures E, all i7-models M, all S -sorted set of variables X (where 
S is the sort set of E) and all valuations p: X ^M, all Wformulas T>, p over 
X ^ with \-^ p: 

if M \=p then M \=p p 

(Absurdity), (Tertium non datur) and (^-elim) are easily seen to be 
sound by inspecting truth tables. Concerning (^-intro), note that the sub- 
proof of fj has assumptions U {p}, hence by induction hypothesis, if M \=p 
T> U {p}, then M \=p ip. From this, we get if M \=p then M \=p p ^ fj. 

(V-elim): M \=pyx: s . p means that M \=p^x^^a] T foi” ^ii ^ C , hence 
in particular M \=p p, since p = p[xs ^ p{xs)]- 

(V-intro): By the side condition, Xg does not occur freely in Hence, 
assuming that M \=p T>, we get M \=p^x^^a] ^ ^ C . By the induction 

hypothesis, for these then M p. Hence, M \=pyx: s . p. 

Soundness of (Reflexivity) and (Totality) are obvious. 

Soundness of (Congruence) and (Substitution) follows from the fol- 
lowing Lemma from [9]. 

Lemma 2.4. Substitution Lemma 

Let M be a E -model, p:Y^M he a valuation, n: X be a substitu- 

tion and p a E -formula over X . Under the conditions that 

^ It may be necessary to extend or shrink the variable set X when applying the 
induction hypothesis. This is no problem, since the induction is over all such 
variable sets in parallel, and since carrier sets of models are non-empty and hence 
satisfaction is not affected by adding or removing extra variables. 
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• o i/: X ^ M is well-defined (i.e. for all x G X 5 , s ^ S we have M \=p 
D(y{xs)) ) and 

• (f[iy] is defined, 

we have 

M ^p*ov ^ if and only if M ^p (p[iy] 

where : TjjiY)^ M is the obvious extension of p to terms. □ 

Soundness of (Function Strictness) and (Predicate Strictness) follow 
from the semantics of function and predicate application, which ensures that 
terms are dehned only if all subterms are dehned, and predicates hold only 
for dehned terms. 

Soundness of (Induction): Let X = {S, TF,PF,P). Given a i7-model 
M, an /S-sorted set V C M\q is {S' , F' ,0)-elosed iff it is closed under the 
application of functions 0{fws)^ with / G F^ and Vs = 0{s)^ for s e S \ S' . 

Lemma 2.5. In the notation of rule Induction, given a valuation p: X^M , 
eonsider the S -sorted set V{p) formed by taking {a \ M \=p^x^^a] ^s} for 
s ^ S' and of 9{s)^ for s ^ S \ S' . 

Then we have 



X[ \=p F ’ ’ ’ F Tk iffP{p) is {S', F' , 9)-elosed. 

Proof. This directly follows from the form of the (pj: p>j states that for any 
argument tuple such that each argument of sort 5 G 5" is in V{p), the ap- 
plication of fj to the argument tuple is in V{p). Since any argument of sort 
s ^ S \ S' trivially is in V{p), this amounts to closure of V{p) under fj. □ 

Now assume that a model M under a valuation p: X ^ M satis- 
hes the premises of the rule. Satisfaction of the sort generation constraint 
{S',F',9: X ^ X) means that the smallest (5", F', ^)-closed set is M\q. Sat- 
isfaction of the second premise by Lemma 2.5 means that V{p) is {S' ,F' ,9)- 
closed. Hence, V{p) is already M\e. But this just means that p satishes the 
conclusion. 

Soundness of (Sortgen-intro): since the predicates ps : 9{s) do neither 
occur in non-local assumptions nor in the conclusion of the rule, it is possible 
to assume that they are interpreted as ‘derm generatedness by the operations 
in 9{F'y\ With this, the premise of the rule reads “if the operations in 9{F') 
preserve term generatedness by the operations in 9{F'), then all elements of 
carriers for sorts in 9{S') are term generated by the operations in 9{F'f \ Since 
the condition before the ‘then’ is trivially true, this means that all elements 
of carriers for sorts in 9{S') are term generated by the operations in 9{F'). 
Hence, the sort generation constraint is true. 

The proof of completeness follows the lines of [9]. □ 
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One may have doubts whether the rule (Sortgen-intro) really can be 
sound. After all, it seems to introduce a second-order principle based on hrst- 
order reasoning. (Note that an induction rule for all hrst-order formulas is 
different from an induction rule with a second-order predicate variable.) How- 
ever, due to the Eigenvariable condition for the predicate symbols mentioned 
in the rule, we actually have some form of universally quantihed predicate vari- 
ables. In particular, in order to derive a sort generation constraint, one usually 
needs a (possibly different) sort generation constraint among the premises. 

Theorem 2.6. If sort generation eonstraints are used, the ealeulus is not eom- 
plete. Moreover, there eannot be a reeursively axiomatized sound and eomplete 
ealeulus for many-sorted Casl basie speeifieations. 

Proof. With sort generation constraints, the second-order Peano axioms can 
be expressed, specifying the natural numbers up to isomorphism. The stated 
results then follow from Godel’s incompleteness theorem (see e.g. [64]). □ 

Since completeness implies compactness (proofs are hnite), incompleteness 
is also a corollary of the following theorem: 

Theorem 2.7. The semantie eonsequenee relation \=^ for many-sorted Casl 
basie speeifieations is not eompaet. ( Compaetness means that every formula 
that follows from an arbitrary set of formulas already follows from a finite 
subset of that set.) 

Proof. From the Peano axioms and {p(5i^c^(0)) | n G N}, we can semantically 
derive Vx : nat.p{x). However, this does not follow from a hnite subset. □ 

Theorem 2.8. The above proof ealeulus satisfies the properties of an entail- 
ment system, i.e. 

1. rehexivity: {p} cp, 

2. monotonicity: if P \~jj p and P' ^ P then P' \-z; 

3. transitivity: if P \~^ pi, for i ^ I, and P U {pi \ i ^ 1} \~e then 

Jf.. translation: if a: Ui^U 2 ciLid P hx-i then o-{P) hx-a 

Proof. Rehexivity and monotonicity directly follow from the notion of deriva- 
tion tree. Transitivity follows by noting that derivation trees can be composed. 
Translation follows by noting that the translation of a proof rule by a signa- 
ture morphism yields an instance of a proof rule. □ 

Instead of using the above calculus, it is also possible to use an encoding of 
the Casl logic into second-order logic. This means that not only subsorting, 
but also partiality are coded out using standard many-sorted hrst-order logic, 
while sort generation constraints are translated to second-order induction ax- 
ioms. Using this encoding, any entailment relation between sets of sentences 
in the Casl logic can be translated to an equivalent entailment in second- 
order logic. Hence, any calculus for second-order logic (or hrst-order logic 
with induction) can be re-used for Casl. The details can be found in [41]. 




3 



Subsorting Specification Calculus 



The logic of subsorted basic specifications is defined via a reduction to many- 
sorted specifications (see Chap. In particular, subsorted i7-sentences are 

many-sorted i7^-sentences for some many-sorted signature constructed 
out of a subsorted signature E. Hence, we can just use the proof calculus 
for many-sorted basic specifications, while adding the following logical axioms 
(taken from the semantics of subsorted specifications): 

Identity: yxs.em^s)^s{xs) = Xg 

Transitivity: (xg)) = (xg) for s < s' < s" 

Projection: '^Xg.pr (xg)) = Xg for s < s' 

Projection-injectivity: \/{xg^ ,yg^}.pr^^,^^s{xg^) = pr^s,^^^{yg') => Xg^ = yg> 
for s < s' 

Membership: \/xg> .in{s) (^^,s^{xg>) D{pr (^g,yg{xgf)) for s < s' 

Function- monotonicity: 

• • • >3^5 , }-e"Z(s), SI (4i>> • • • > 

= em(s-),s- (/«,/, • • • > em(s„),s^ ))) 
for fw,s ~F fw’,s'^ where w' = {s[,...,s'„) and w = (si,...,s„), with 
w < w,w' for some w = (si , . . . , 5^) , and 5, s' < s" 

Predicate- monotonicity: 

• • • ’ erra{s„),s„(a;^„)) 

for Pw Pw'^ where w' = . . . , s'^) and w = (si, . . . , 5^), with w < 

w^w' for some w = (si, . . . ,5^) 

Soundness and completeness results directly carry over from the many- 
sorted case. 

It seems hard (if not impossible, without further assumptions on the signa- 
tures) to build a subsorted calculus directly working on the Casl input syntax 
(i.e. without fully qualified symbols). This has been done for 0BJ3 [25]. How- 
ever, the calculus of 0BJ3 imposes special requirements on signatures such as 
regularity, which are not present in Casl. 




4 



Structured Specification Calculus 



For structured theorem proving, there are several possible ways to go. One 
possibility is to directly work on the language of Casl structured specihca- 
tions, as e.g. in [58]. However, the corresponding calculus becomes inevitably 
rather complex, and soundness (let alone completeness) is hard to see. 

The other possibility, which we will follow here, is to use a kernel language. 
We use so-called development graphs as a simple kernel formalism for struc- 
tured theorem proving and proof management. A development graph consists 
of a set of nodes (corresponding to whole structured specihcations or parts 
thereof), and a set of arrows called dehnition links, indicating the dependency 
of each involved structured specihcation on its subparts. 

The link between Casl structured specihcations and development graphs 
is given by a verifieation semanties. It is similar to the static semantics of 
structured specihcations, but simultaneously extracts a development graph 
and a set of proof obligations (the latter are called theorem links). The proof 
obligations arise e.g. from instantiations of generic specihcations. There is an 
adequacy theorem stating that the proof obligations can be discharged if and 
only if the model semantics of the structured specihcation under consideration 
succeeds. Further proof obligations are generated by semantic annotations 
such as %implies and %cons. 

The proof ealeulus for development graphs is given by rules that allow 
for decomposing global theorem links into simpler ones, until eventually loeal 
implieations are reached. The latter can be discharged using a logic-specihc 
calculus as introduced in Chap. 2. We also address soundness and complete- 
ness of the proof calculus. 

Let us now add some remarks about the choice of the kernel language. 
Development graphs are not the only possible choice. Another choice would 
be the simple kernel language of structured specihcations given in [7]. The 
drawback of this approach is that its calculus is based on the rather strong 
assumption that the institution has the Craig interpolation property. By con- 
trast, the calculus for development graphs is based on a different assumption, 
namely the existence of weakly amalgamable cocones (cf. Def. 4.1). Note that 
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Craig interpolation (although technically incomparable in strength with the 
property of existence of weakly amalgamable cocones) for practical purposes 
is the stronger property (cf. the results of [17]). The deeper reason of these 
differences is that the calculus for development graphs contains global rules for 
graphs involving hiding that introduce additional nodes corresponding to nor- 
mal forms of structured specihcations (note however that the structure of the 
specihcation is still kept). By contrast, the rules for structured specihcations 
developed by Borzyszkowski [7] are entirely locals which exactly is the reason 
why the Craig interpolation property is needed to achieve completeness. 

An important practical difference of the two approaches is the following. 
In contrast to the kernel language of structured specihcations, development 
graphs allow for expressing the sharing among specihcations due to multiple 
references to named specihcations. Moreover, the proof management tools for 
Casl work directly on development graphs; hence, the material presented 
here can serve as a formal background for the use of these tools and for the 
understanding of how they work. Last but not least, development graphs also 
support management of change. 

Development graphs are a device for dealing with structured specihcations. 
They should not be confused with the (formally quite similar) diagrams aris- 
ing in the extended semantics of architectural specihcations (see Sect. 111:5.6). 
The crucial difference is in the role of hiding when a specihcation is used 
twice, with parts of it hidden in both cases. If a specihcation SPEC occurs 
within a structured specihcation, then the semantics rehected by the develop- 
ment graphs requires that the overall model can be extended with the hidden 
parts for each occurrence of SPEC separately. In contrast, if a unit UN : SPEC 
is used within an architectural unit term, then the semantics rehected by the 
architectural diagrams requires that the overall model can be uniformly ex- 
tended with the hidden parts to a single model of SPEC, common for all the 
occurrences of UN . This amounts to saying that a global model of the colimit 
of the architectural diagram can be constructed. This is not possible for de- 
velopment graphs. Although there is a colimit construction for them as well, 
it is different in that the diagram is not given directly by the development 
graph, but by the diagram of all paths in the development graph (cf. the rule 
(Theorem-Hide-Shift) in Sect. 4.4 below). 



4.1 Institution Independence 

In order to achieve independence from the specihc framework of basic speci- 
hcations, we assume that we have an entailment relation for basic specihca- 
tions (either given by some proof calculus, or by some logical encoding, or in 
some other way). Based on this, the proof calculus in this chapter is largely 
logic-independent. A framework for basic specihcation formally consists of an 
institution (Sig, Sen, Mod, ^) [20] together with a sound entailment system 
h for the institution (this is also called a logic). Here, an entailment system 
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is a family of relations (hx- ^ V{Seu{U)) x Sen(i7))^^|Sig| between sets of 
sentences and sentences that is required to satisfy the properties listed in 
Theorem 2.8. 

Additionally, we need a technical assumption about the logic, namely that 
every hnite diagram of signatures has a weakly amalgamable cocone. We now 
explain what this means. 

Definition 4.1. Given a diagram D: J^Sig a family of models {Mj)j^\j\ 
is ealled D-consistent if Mk\D(S) = for eaeh S: j ^ k G J. A eoeone 
(A, {fiji D{j) ^ U)j^\j\) over the diagram D: J^Sig is ealled weakly amal- 
gamable if for eaeh D-eonsistent family of models {Mj)j^\j\, there is a U- 
model M with = Mj (j G \J\)- If this model is unique, the eoeone 

is ealled amalgamable. If additionally also model morphisms ean be uniquely 
amalgamated in this way, the eoeone is ealled morphism- amalgamable. A logie 
is said to admit weak amalgamation, if eaeh finite diagram of signatures has 
a weakly amalgamable eoeone. 

Proposition 4.2. The Casl logie for many-sorted basie speeifieations admits 
weak amalgamation. 

Proof. According to Theorem 111:2.17, it suffices to take the colimit of the 
diagram - this is even morphism-amalgamable. □ 

Note that this proposition does not hold for subsorted specihcations, see 
[63]. But we provide a way around this problem: it suffices that the logic at 
hand can be represented in a logic admitting weak amalgamation. 

In order to dehne what such a representation means, we need some aux- 
iliary notions. Given an arbitrary institution, a theory is a pair T = {U,T), 
where U G Sig and T C Sen(A) (we set Sig{T) = U and Ax{T) = T). Theory 
morphisms a: {U,T) ^ {U' ,T') are those signature morphisms a: U ^ U' for 
which T' rr{T), that is, axioms are mapped to logical consequences. 

By inheriting composition and identities from Sig, we obtain a category 
Th of theories. It is easy to extend Sen and Mod to Th by putting 
Seu{{U,T)) = Sen(A) and letting Mod((A,!Z^)) be the full subcategory of 
Mod(A) induced by the class of those models M satisfying T. The category 
Pres of presentations (also called fiat speeifieations) is just the full subcate- 
gory of theories having hnite sets of axioms. 

Given institutions I and J, a simple theoroidal institution eomorphism 
[23, 34, 65] (also called simple map of institutions [34] or simple institution 
representation) R= (T>,a, (3): I ^ J consists of 

^ Diagrams have been introduced in Sect. 111:5.6. 
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• a functor Sig^ ^Pres"^,^ 

• a natural transformation a : Sen^ ^ Sen"^ o 

• a natural transformation [3 : Mod"^ o ^Mod^ 

such that the following comorphism condition is satished for all U G Sig^, 
M' G Mod^(^(i:)) and p G Sen^(i:): 

\=Sig(<P(S)) Ots{^) Ps{M') Lp. 

A comorphism is called model-isomorphic^ if each model translation fSjj is 
an isomorphism. 

Remark 4-3. General assumption: The given institution is embedded via 
a model-isomorphic simple theoroidal institution comorphism R = (^, o, f3) 
into an institution that comes with an entailment system (i.e. forms a logic) 
and furthermore admits weak amalgamation. 

Note that this assumption is fulhlled for the subsorted Casl institution: 
it can be embedded into the many-sorted Casl institution as indicated in the 
semantics of subsorted specihcations. Another possibility is to embed Casl 
into enriched Casl as described in [63]. The advantage of using the many- 
sorted Casl institution is its simplicity (compared with enriched Casl), the 
advantage of enriched Casl is that the comorphism is simpler and moreover 
we keep the subsorting structure, which may be exploited by special calculi 
[31], 

Remark 4-4- We will use the general assumption tacitly in the following sense. 
At one place of the proof calculus, we rely on the fact that the underlying 
institution comes with an entailment system, and at several places, we need 
the existence of weakly amalgamable cocones - and we will presume that the 
institution we are working with enjoys these properties. Even if the institution 
should fail to satisfy them, we can translate the constructed development 
graph along the comorphism given by the general assumption, and we can 
rely on the target institution having the needed properties. The translation 
of development graphs, together with the fact that it is sound and complete, 
is given in Sect. 4.3 below. Note that in practice, one might wish to use 
the translation in a rather flexible way, namely only in those cases where 
a weakly amalgamable cocone does not exist in the original institution. This 
will be possible in the framework of heterogeneous specihcations [40]. Another 
possibility is to limit the rules of the proof calculus to those cases where all 
needed weakly amalgamable cocones already exist in the original institution. 
However, this will lead to a loss of completeness for institutions that do not 
admit weak amalgamation (although this loss might not be severe in practice). 

^ Meseguer [34] requires Th^ but since p is theoroidal, both formula- 

tions are equivalent using Meseguer ’s o-extension (except for the fact that we use 
presentations instead of theories). 
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4.2 Development Graphs 

Development graphs are structured as follows. Leaves in a graph correspond 
to basic specifications, which do not make use of other specifications. Inner 
nodes correspond to structured specifications. The finks that capture the con- 
struction of structured specifications in the graph are called definition links. 
Arising proof obligations are attached as so-called theorem links to this graph. 

Definition 4.5. A development graph is an aeyelie, direeted graph VQ = 

Af is a set of nodes^ . Eaeh node N ^ Af is labelled with a pair 
sueh that is a signature and C Seu(E^) is the set of local axioms 
ofN. 

C is a set of direeted links, so-ealled definition finks, between elements of 
Af. Eaeh definition link from a node O to a node N is either 

• global ( denoted O ^ > N ), annotated with a signature morphism a : 

EO 

• local ( denoted O — N ), again annotated with a signature morphism 
a:E^ ^ E^, or 

• hiding ( denoted O > N ), annotated with a signature morphism a : 

E^ E^ going against the direction of the fink, or 

• free ( denoted O ^ > N ), annotated with a signature morphism a : E ^ 

free 

E^ for some signature E, with the requirement that E^ = E^ . 

To simplify matters, we write O ^ > N G VQ instead of O ^ > N ^ C 
when C are the finks of VQ. We use N , O, P, Q, K as variables for nodes, 
and L as variable for finks. 

Since development graphs are acyclic, we can use induction principles in 
definitions and proofs concerning development graphs. 

The next definition captures the existence of a path of local and global 
definition finks between two nodes. Notice that such a path must not contain 
any hiding finks. 

Definition 4.6. Let VQ be a development graph. The notion of global reach- 
ability is defined induetively: a node N is globally reaehable from a node O 
via a signature morphism a, O N for short, iff 

• either O = N and a = id, or 

• O ^ > P ^ VQ, and P ^ N , with a = a" o a' , or 

• O ^ > P G VQ and P N (note that a' is just ignored here). 

free 

^ The structure of nodes is left unspecified here; we assume that they come from 
some set Nodes of nodes, and new nodes are available as discussed in Sect. 111:5.6. 
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A node N is locally reachable from a node O via a signature morphism a, 

0> ^ N for short, iff O ^ N or there is a node P with O — P C 

VQ and P > N, sueh that a = a" o a' . Note that, in eontrast to global 
reaehability, loeal reaehability is not transitive. 

Obviously global reachability implies local reachability. 

Definition 4.7. Given a node N G M, its assoeiated elass Modpg(A^) of 
models (or N -models for short) is induetively defined to eonsist of those - 
models M for whieh 

1. M satisfies the loeal axioms , 

2. for eaeh O ^ > N G VQ, M|cr is an O -model, 

3. for eaeh O — N G VQ, M|cr satisfies the loeal axioms , 

4 . for eaeh O > N G VQ, M has a a -expansion M' (i.e. M'\cr = M) 
that is an O-model, and 

5. for eaeh O ^ > N G VQ, M is an O-model that is a -free in Mod(O). 

free 

The latter means that for eaeh O-model M' and eaeh model morphism 
h: M\cr^ M'\cr, there exists a unique model morphism h^ : M^M' with 
h*\^ = h. 



Definition 4.8. Let VQ = {Af,jC) be a development graph. A node N e Af 
is flattenable iff for all nodes O G A/* with ineoming hiding or free definition 
links, it holds that N is not globally reaehable from O. 

Definition 4.9. Let VQ = {M,C) be a development graph. For N G Af, the 
theory Thx>g{N) of N is defined by 

IJ cr(!f'^) 

N 

Proposition 4.10. 1. O N and M eM.od{N) imply M\cr^'M.od{0). 

2 . IfO>^^N and M eMod{N), then M\^ ^ . 

Proof. 1. Easy induction over the dehnition of global reachability. 

2. By 1 and Dehnition 4.7, 3. 

Proposition 4.11. 1. Mod(A^) C M.od{Thj)g (N)) . 

2. If N is flattenable, then Mod(A^) = N\.od{Thjyg{N)) . 

Proof. 1. By Proposition 4.10, 2 and Dehnition 4.7, 1. 

2. By 1, it suffices to prove the ‘D’ direction. Let M be a ThT>g{N)-mode\. 

Let len{p) be the length of a path p witnessing O ^ N . Let maxp be 
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the maximal such length in VQ. We show that for any O ^ N ^ M\^ is 
an O- model. We proceed by induction over maxp — len{p) with p witnessing 

O ^ N. Since N is flattenable, we only have to show clauses 1 to 3 of 
Definition 4.7: 

1. Since global implies local reachability, 0> ^ and r{^^) C Thvg{N)] 

hence M \= By the satisfaction condition for institutions, M\^ \= 

2. Let P ^ > O, hence P N. By the induction hypothesis, M\ro 0 is 

a P-model. 

3. Let P — O, hence P> N. With a similar argument as for 1, we 
get M\ro0 h 

%d 

This completes the induction. Since N N ^ M is an Wmodel. □ 

Complementary to definition finks, which define the theories of related 
nodes, we introduce the notion of a theorem link with the help of which we 
are able to postulate relations between different theories. Theorem finks are the 
central data structure to represent proof obligations arising in formal devel- 
opments. Theorem finks come, like definition finks, in four different versions: 

• global theorem links 0 = = ^ where a: 

• loeal theorem finks O - - ^ N where a: P^ ^ P^ ^ 

• hiding theorem finks 0 = = ^ where for some P, 0: P ^ P^ and 

hide 0 

a: and 

• free theorem links O = = => N, where a : E^ and for some E,0: E ^ 

free 6 

P^ . In case that P is the initial signature and 0 is the unique signature 
morphism, the fink is written as O = = ^ 

free ! 

Moreover, we will also need loeal implieations of the form ^ P, where W 
is a set of P^-sentences. N ^ {p} also is written N ^ p. The semantics of 
local implications and of theorem links is given by the next definition. 

Definition 4.12. Let VQ he a development graph and O, N nodes in VQ. 

• VQ implies a loeal implieation N ^ , written VQ \= N ^ , if for all 

M eModvg{N), 

• VQ implies a global theorem link 0 = = ^N (denoted VQ ^ O = = ^ N) 
iff for all M G Modvg{N), M\^ G Modpg(O). 



Here, a is the reduction morphism (comparable to that of global theorem links), 
and 0 is the hiding morphism (extending a signature with hidden parts). 
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• VQ implies a local theorem link O - - ^ N ( denoted VQ \= O - - ^ N) 
iff for all M G M.odj)g{N), M|cr H (^ote that by the satisfaction 
condition, this is equivalent to VQ \= N ^ 

• VQ implies a hiding theorem link O = = ^ N ( denoted VQ t O = = ^ N) 

hide 6 hide 6 

iff for all M G 'M.odj)g{N), M\cr has a 0 -expansion to some O -model. 

• VQ implies a free theorem link O = = ^ N ( denoted VQ t O = = ^ N) 

free 6 free 6 

iff for all M G 'M.odj)g{N), M|cr is an O -model which is 6 -free in 
Modpg(O). 

Remark Note that theorem links may be captured by inclusion between 
model classes of some (additional) nodes in the development graph. For in- 
stance, consider a hiding theorem link O = = ^ in a development graph VQ, 

hide 6 

where 0: E ^ and a: E ^ E^ . One can add nodes N' and N" to VQ , 
with E^' = E, E^" = E^ , and " = 0, together with dehnition 

links O ^ > N' and N' ^ > N'k For the thus obtained development graph 

hide 

VQ' , we then have 

VQ^ O N iff Modj,g>{N) C Modj,g>{N") 

A similar construction can be performed for the other types of theorem 
link. □ 



Finally, we introduce the analogues of the semantic annotations in Casl. 
A global theorem link Q = = ^ N can be strengthened to 

• a conservative extension^ (denoted as O A^); it holds if, additionally 

to the holding of the theorem link, every O-model has a a-expansion to 
an A^-model, 

• a monomorphic extension (denoted as O A^); it holds if, additionally 

to the holding of the theorem link, every O-model has a a-expansion to 
an A^-model that is unique up to isomorphism, or 

• a definitional extension (denoted as O = = ^ A^); it holds if, additionally to 

def 

the holding of the theorem link, every O-model has a unique a-expansion 
to an A^-model. 

These annotations can be seen as another kind of proof obligations. If there 
happens to be a global dehnition link O ==^ N in the development graph, we 

^ In the literature on model theory, this property is often called model expan- 
sion property, while the term eonservative extension refers to a (weaker) proof- 
theoretic principle. 
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also write O O or O ^ respectively. In this case, the 

con mono 

theorem link part holds trivially, and only the conservativity, monomorphicity 
or definitionality statement is relevant. 

We also allow for annotating nodes with cons, mono or def . This shall ex- 
press that the trivial theorem link using the unique signature morphism from 
the empty signature^ could be annotated with the same word^. Thus, the 
annotation cons for a node means that there is a model of the node (consis- 
tency), mono means that the node has exactly one model up to isomorphism 
(i.e. it is monomorphic) , and def means that the node has exactly one model 
(the latter will occur only rarely). 



4.3 Translating Development Graphs 
along Institution Comorphisms 

Given a model-isomorphic simple theoroidal institution comorphism R = 
^ J, we can extend this comorphism to a translation of devel- 
opment graphs over I into development graphs over J in the following way: 
Given a development graph VQ over /, let R{VQ) have the same nodes and 
links as VQ (for clarity, given a node N G VQ^ we call the corresponding node 
R{N) G R{VQ)^ and similarly for definition finks). The associated signatures, 
local axioms and signature morphisms differ, of course: 

• if G VQ, then = Sig{^{U^)), and 

U Ax{${E^)) 

• the signature morphisms decorating a link L are translated along and 
intermediate signatures U are replaced with Sig(^{E))^ yielding a fink 
R{L). 

Theorem 4.14. Given a model-isomorphic simple theoroidal institution co- 
morphism R = (3): I ^ J and a development graph VQ over I, for each 

N G VQ, the isomorphism 

PsN : Mod(r^)^Mod(^>(r^)) 

restricts to the isomorphism 

Mod(A^)^Mod(i?(A^)) 

Proof. First, note that indeed Mod(i?(A^)) C Mod(^(T^)), because 
includes Ax{^{U^)). We now proceed by induction over VQ. Hence, it suffices 
to show for each M G Mod(^(T)): 

® We here assume that the empty signature is initial. 

^ Here we tacitly assume that there is some special node having the initial signature 
and the empty set of axioms. 
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1. (3jjn{M) h iff M h 

2. for any ingoing definition link L into (3jjn (M) satisfies L iff M satisfies 
R{L). 

Both can be shown in a straightforward way, using the satisfaction condition 
of the comorphism, natnrality and isomorphism property of f3 and the fact 
that for any /-signature morphism a, ^(cr) is a theory morphism. □ 

Theorem 4.15. Given a model- isomorphic simple theoroidal institution co- 
morphism R= I^J and a development graph VQ over /, let L he 

a theorem link over VQ. Then 

VQ ^ L iff R{VQ) ^ R{L) 

Proof. By Theorem 4.14 and Remark 4.13. □ 

Note that with this translation of development graphs along comorphisms, 
new local axioms coming from Ax{^{U^)) are often partly repeated. One can 
optimize this by adding at each node only those axioms from Ax{T>{U^)) that 
are not already present via links from other nodes. 



4.4 Proof Rules for Development Graphs 

In this section, we introduce logic-independent proof rules for development 
graphs. These rely on a logic-specihc entailment relation for basic specihca- 
tions as introduced in Chap. 1, as well as on logic-specihc proof rules for 
conservativity and freeness, which will be covered in Sect. 4.6. 

The proof rules work on judgements of the form VQ h L, where VQ is 
a development graph and L is a theorem link (of any kind) over VQ. As 
in the calculus for basic specihcations, we follow a natural deduction style 
presentation and additionally use a graph-grammar like notation. We hope 
that this is still largely self-explanatory while improving readability. 

The proof rules for development graphs presented below are typically ap- 
plied backwards: given proof goal in form of a theorem link relative to some 
development graph, hnd a rule whose conclusion matches the proof goal, and 
recursively prove the premises of the rule. Note that within one rule, the 
judgements may refer to different development graphs. Often, the premises 
are formulated over development graphs that are larger than that for the con- 
clusion. This means that applying rules backwards possibly adds some new 
nodes and edges to the development graph. 

The rules allow for decomposing global theorem links into simpler ones. 
In a hrst step, one typically tries to get rid of hiding theorem links and to de- 
compose global into local theorem links. This is done by applying the hiding 
decomposition rules. Thereby, new conservativity proof goals can be gener- 
ated, which need to be tackled by the conservativity rules. The simple de- 
composition rules then allow for proving global theorem links when there is 
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some parallel definition link, and for proving local theorem links and local 
implications by reasoning with the entailment system of the logic. 

For the sake of readability, each rule is followed by its soundness proof. 



4.4.1 Hiding Decomposition Rules 

In order to get rid of hiding links going into the source of a global theorem 
link, one first applies (Glob-Decomposition), ending up with some local 
and hiding theorem links. The rule (Hide-Theorem-Shift) allows to prove 
the latter, using conservativity of definition links. (Borrowing) can be used 
for shifting a proof goal along a conservative extension; hence, it also exploits 
conservativity of theorem links. Conservativity is dealt with in the next sec- 
tion. The central rule of the proof system is the rule (Theorem-Hide-Shift). 
It is used to get rid of hiding definition links going into the target of a global 
theorem link. 



N' 

^ ^ Q'^ cons 



O' N 



^ hide% ^ 

\i a' o 0 = O' o(j 



(Hide-Theorem-Shift) 

The proof rules are written in a concise notation as above. We will spell 
out in detail what this notation means for the rule (Hide-Theorem-Shift): 



a' o 0 = O' o a 
N N' e vg 
N = J„^ N' 



vg ^ O' = = ^ N' 






Soundness of (Hide-Theorem-shift): assume that VQ ^ O' = = ^ N' 
and N = = ^ is conservative. We have to show that VQ \= O' = = ^ Let 

cons hide 6 

Qf 

M be an Wmodel. Since N = conservative, M can be expanded to 

an A^'-niodel M' with = M. By the assumption, M'\cr' is an O'-model. 

Thus, M'\cr>oe = M'\0>oa = M\cr has a ^-expansion to an O'-model. □ 




300 



IV:4 Structured Specification Calculus 



Gn{^) 




with K isolated and (/x^) a weakly amalgamable co- 
cone for the diagram Diag^ of nodes going into N 
(see explanation below) 

( Theorem- Hide- S hift ) 

Since this rule is quite powerful, we need some preliminary notions. Given 
a node in a development graph VQ = (A/*, C ) , the idea is that we unfold 
the subgraph below N into a tree and form a diagram with this tree. More 
formally, dehne the diagram Diagj^ : J Sig associated with N together with 
a map Gn: \J\^Af inductively as follows: 

• (N) is an object in J, with Diag j^{{N)) = . Let Gn{{N)) be just N . 

• if X = ( O — ) is an object in J with Li, . . . , non-local 

dehnition links in £, and L = P ^ > O or L = P — O is a local or 

global dehnition link in £, then 

, / Jj J-j 1 J-j \ 

J = (P ^N) 

is an object in J with Diagj^{j) = and L is a morphism from j to i 
in J with Diagj^{L) = a. We set GnU) = P- 

• if X = ( O — > A^ ) is an object in J with Li, . . . , non-local 

dehnition links in £, and L = P ^ > O is a hiding dehnition link in £, 

hide 

then 

/ L Li Ln s 

J = (P ^N) 

is an object in J with Diagpf{j) = , and L is a morphism from i to j 

in J with Diag^{L) = a. We set GnO) = P- 

Now in order to apply (Theorem-Hide-Shift) , take a weakly amalgam- 
able cocone (i7, (/x^ : Diag j^{i) ^ E)i^\j\) for Diag^^ (it exists by Remark 4.4), 
and let iL be a new isolated node with signature P and with ingoing global 

dehnition links G^ii) > K for x G |J| (if GN{i) has no ingoing free def- 
inition links, a local dehnition link GN{i) > iL would suffice). Here, an 
isolated node is one with no local axioms and no ingoing dehnition links other 
than those shown in the rule. 
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We once more spell the rule in detail: 



(i7, {fii’. Diag j^{i) ^ U)i^\j\) is a weakly amalgamable cocone for Diagj^ 
vg' = Vg\S{K with (r, 0)} W { Giv(i) K\ie I J|} 



vg' h 
vg h 



M(AT) OCT 
0 = = 



0 = = ^N 



Here, if we want to extend a given development graph VQ^ we use a sugges- 
tive concise notation like VQ' = VQ l±) {N' with N N'} which 

should be largely self-explanatory (in particular, W' with (i7', means that 
we introduce a new node N' with = U' and = ^). 

IJ, 0(7 

Soundness of (Theorem- Hide- Shift): assume that VQ ^ O = = ^ K- 
Let M be an Wmodel. We have to show M|cr to be an O- model in order to 

establish the holding of O = = ^ We inductively define a family 
of models Mi G Mod(G 7 v(z)) by putting 

• ^{N) = 

• M . ^ ^ = M'Icr, where L = P Q or L= P — Q 

and M' = M . . , and 

• M ^ ^ ^ is a (7-expansion of M' to a P-model (existing 

since M' is a Q-model), 

where L = P ^ > Q and M' = M ^ ^ 

hide ^ 

It is easy to show that this family is consistent with Diagj^. Since by the side 
condition of the rule, (P, {fii : Diagj^{i) ^ P)i^\j\) is a weakly amalgamable 
cocone, there is a P^-model Mk with Mk\im = Mi. The latter implies that 
Mk is a iL-model. By the assumption, = M^ 7 v)|cr = M\a is an 

O-model. □ 



O N 

II II 

q\\ q'W cons 

O' = = ^ N' 

a 



0= = 7>N 

II II 

qW 0'W cons 

O' 

if (j' o ^ o (7 

(Borrowing) 
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Soundness of (Borrowing): Assume that (1) VQ \= O = = ^ Oh (2) 

H N H O' = = ^ N'^ Let M be an A^-model. 

By (2), M has an expansion to an A^'-model M' with M'\ef = M. By (3), 
M'Icr' is an O'-model, and hence, by (1) M'|cr'o6> = Af'l^i'ocr = Af|cr is an O- 
model. □ 



p Q fQj. py ^ > TV 

Q (9 for each Q ^ > P and P ^ 

hide 6 hide 

Q Q for each Q ^ > P and P ^ N 

free 6 free 

(Glob-Decomposition) 

Soundness of (Glob-Decomposition): assume that 

1. h -P O for each P>^^N, 

2. VQ t Q ='^=%’ O for each Q ^ > P and P N, and 

hide 6 hide 

3. pg k Q ='"=^=> o for each Q P and P N. 

free 9 free 

In order to show VQ ^ = = ^ O, let M be an O-model. Let len{p) 

be the length of a path p witnessing P ^ )^> N . Let maxp be the maximal 
such length in VQ. We show that for any P ^ > N ^ Mjcror is a P-model. 

We proceed by induction over maxp — len{p) for p witnessing P ^ N . We 
have to show clauses 1 to 5 of Dehnition 4.7: 

1. By the hrst assumption, Mjcror H 

2. By the induction hypothesis, Mjcror satishes any global dehnition link 
going into P. 

3. By the hrst assumption, Mjcror satishes any local dehnition link going into 
P. 

4. By the second assumption, Mjcror satishes any hiding dehnition link going 
into P. 

5. By the third assumption, Mjcror satishes any free dehnition link going into 
P. 

^ A^, Mjcr is an A^-model. □ 



This completes the induction. Since N 
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4.4.2 Conservativity Rules 



0= = ^N 

e^cons ^ O'l 

O' 

N 

e'^cons 

N' 






a 



jjN 



if 






1”^ 

jjN' 



is weakly amalgam- 
able and N' is iso- 
lated. 



(Cons- Shift) 



Q 

Soundness of (Cons- Shift): Assume that O O' is conservative. We 

Qf 

have to prove that N N' is conservative as well. Let M be an Wmodel. 

Since O O' is conservative, M|cr has a ^-expansion M' being an O'- 

model. By weak amalgamation, there is some -model M' with M'\(j' = M' 
and M'\of = M. Since N' is isolated, M' is an A^'-niodel. □ 



0= = ^N 

O' =^N' 
N 

0'^def 

N' 



if 



E'=' ■ 
0 



0 ' 

Y 

y^N' 



is amalgamable and 
N' is isolated. 



(Def-Shift) 



0 

Soundness of (Def-Shift): assume that 0--^0' is definitional. We 

def 

0f 

have to prove that N is definitional as well. Let M be an Wmodel. 

def 

By the argument used for the proof of soundness of (Cons-shift), M has a 0'- 
expansion to an A^'-niodel M' . Now let M" be another A^'-niodel with M"\of = 

M = M'\ 0 ,. Then M '\,,,0 = = M"\ 0 ,,, = M"\,,,e. Since 0 = =fO' 

is definitional, M'\(j> = . By uniqueness of the amalgamation, M' = M" . 

□ 
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0=inf’N 

cons II 0 

N' 



O con^ N 

^ n " 

Cocr ^11 cons 

cons , 'll 



(Cons-Composition) 

Soundness of (Cons-Composition): any O- model can be a-expanded to 
an A^-model, which in turn can be ^-expanded to an A^'-niodel. Hence, each 
O-model can be ^ o a-expanded to an A^'-model. □ 

0=Jn^N 

II 

mono II 0 

N' 



O moT^ N 

^ a " 

0OCT ^11 mono 

mono , nIL 
^ V 



if 0 is transportable, any hiding link going directly or indirectly into N' has 
a transportable signature morphism, and satisfaction in the institution is 
closed under isomorphism 

(Mono-Composition) 

For the rule (Mono-composition), we need some technical notion: call 
a signature morphism a: U2 transportable^ if for any i7i-model Mi and 

i72-model M2 and any isomorphism hi : M2|cr^Mi, there is a i72-model M^ 
and an isomorphism /z2 : M2 ^ with h2\a = hi (which of course includes 
M^lcr = Ml). Usually, transportability can be characterized syntactically. For 
example we have: 

Proposition 4.16. In the Casl institution, a signature morphism is trans- 
portable iff it is injeetive on sorts. 

Proof. Let a sort- injective a: Ui^U2, a Ui-model Mi, a ^2-model M2 and 
an isomorphism hi: M2\a Mi be given. M^ is constructed by taking Mi, 
and extending it with the carriers of M2 for sorts in U2 \ Ui. Operations 
and predicates in E2 \ PIi are interpreted as in M2, possibly composed with 
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appropriate parts of hi whenever sorts from Ui are involved as source or 
target sorts. This construction works if a is injective on sorts. If not, take 
sorts with (7(5) = cr(t), take M2 arbitrary and take Mi as M2|cr except 
that is not , but is replaced by some isomorphic copy of (and again 
operations are composed with this iso if necessary). Then it is impossible to 
find a i72-expansion of Mi. □ 

Soundness of (Mono-Composition): we first show that the model class 
of N' is closed under isomorphism. Let len{p) be the length of a path p 

witnessing P ^ N' . Let maxp be the maximal such length in VQ. We show 
that for any P ^ N' ^ the model class of P is closed under isomorphism. 
We proceed by induction over maxp — len{p) for p witnessing P ^ . 

We have to show that the conditions of clauses 1 to 5 of Definition 4.7 are 
invariant under model isomorphism: 

1 . Holding of sentences in a model is invariant under model isomorphism, by 
the assumption that satisfaction in the institution is closed under isomor- 
phism. 

2. Since reduct functors preserve isomorphisms, we can apply the induction 
hypothesis. 

3 . Here, a combination of the above two arguments applies. 

4 . Let O ^ > P ^ PQ-, M' be a P-model and M" be isomorphic to Mb 

hide 

Since M' is a P-model, it has a a-expansion to an O-model M. By 
transportability of a, there is a P^-model M' isomorphic to M with 
M'\cr = M". By induction hypothesis, Mod(O) is closed under isomor- 
phism, hence M' G Mod(O) as well, and thus M" G Mod(P). 

5 . Freeness is closed under isomorphism. 

This completes the induction. Since N' N\ the model class of N' is 

closed under isomorphism. 

Now we come to monomorphicity of the theorem link O = =^ Let 
M be an O-model. By the two monomorphicity assumptions, it has at least 
one A^'-expansion. So it remains to prove that all A^'-expansions are isomor- 
phic. Let M3 and M3 be two A^'-expansions of M. By monomorphicity of 

O = = ^ Ms\e and M^'le are isomorphic. By transportability of there is 
some M3' isomorphic to M3 with Ms"\e = Ms'\e. Since the model class of N' 
is closed under isomorphism, M3' is an A^'-model as well. By monomorphicity 

of N = = ^ Nh ^3 is isomorphic to M3. □ 
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def 1 1 e 

N' 



0 = if^N 

^ . " 

^6>ocr 0\\ def 

def'^^ ^ 

N' 

(Def-Composition) 

Soundness of (Def-Composition): a global theorem link 0 = -^A^ is 
definitional iff Mod(cr) : Mod(A^) ^ Mod(O) is bijective. Bijective maps 
compose. □ 



0 = =f>N 



O mono N 

(Def-to-mono) 

Soundness of (Def-to-mono): obvious. □ 



O =rd^ N 

O ~cor^ N 



(Mono-to-cons) 

Soundness of (Mono-to-cons): obvious. 



□ 



O 



free 



•N 



K = = ^N 

cons 



K moT^ N 



(Free-is-mono) 

Soundness of (Pree-is-mono): by the second premise, each i^-model has 
a cr-expansion to an A^-model. It remains to show that these a-expansions 
are unique up to isomorphism. But this follows since A^-models are free (and 
hence unique up to isomorphism) over their a-reducts. (Notice that the same 
signature morphism is used in both premises.) □ 
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O 

mono 



a 






^ I " iV 

mono ■ 

(Mono-is-free) 

Recall that ! : 0 ^ is the signature morphism starting from the initial 
signature. 

Soundness of (Mono-is-free): recall that the free theorem link holds if 
for any A^-model M, M|cr is an O- model that is !-free in Modpg(O). Now for 
an model M, M|cr is an O-model by the premise of the rule, and it is !-free 
since in a monomorphic model class, any model is initial (and initiality is just 
!-freeness). □ 



4.4.3 Simple Structural Rules 

The calculus finally provides a set of decomposition rules not interacting with 
hiding nor freeness, and a rule allowing for reducing local implications to 
inference in the calculus of the logic for basic specifications. 

O =^N 

(Subsumption) 

Soundness of (Subsumption): Obvious. □ 

P- - n 

if Q =J^ O and r{P^) = 0{a{P^)) 

p--^o 

(Loc-Decomposition I) 

Soundness of (Loc-Decomposition I): assume VQ \= P--^Q and 

Q ^ O and r{P^) = 0{a{P^)). In order to show VQ \= P - - ^ O, let 
M be an O-model. By Prop. 4.10, M\o is a Q-model, and by the assumption, 
M\ooa \= By the satisfaction condition for institutions, M \= 0oa{P^) = 
r{P^). Again by the satisfaction condition, M\^ \= . □ 
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0--^N 



if cr(!f'°) = e{^^) 



(Loc-Decomposition II) 



Q 

Soundness of (Loc-Decomposition II): assume that 0> N and 
a{^^) = 0{^^). Let M be an A^-model. By Proposition 4.10, M\o \= . By 

the satisfaction condition for institutions, M \= 0(^^) = Again by 

the satisfaction condition, M\cr \= . □ 



N => a{^^) 

0--^N 

(Local Inference) 

Soundness of (Local Inference): assume that M \= a(^^) for each 
A^-model M. In order to show VQ \= O - - ^ let M be an A^-model. 
By assumption, M \= By the satisfaction condition for institutions. 



Thj)g{N) \-jjN (f for each (f 
N 

(Basic Inference) 

Soundness of (Basic Inference): assume that ThT>g{N) \~jjn (p for each 
p e By soundness of C^at, we get Thj)g{N) \=^n W. In order to show 
VQ ^ ^ !Z^, let M be an A^- model. By Proposition 4.11, M \= Thx>g{N). 

Since Thj)g{N) \=jjn also M 



4.5 Soundness and Completeness 

Proposition 4.17. The rules in Seet. 4-4 sound. 

Proof. For each rule, in Sect. 4.4, a soundness proof has been given. 

Another question is the completeness of our rules. We have the following 
counterexample : 

Proposition 4.18. Let FOL he the usual first-order logie with a reeursively 
axiomatized eomplete entailment system. The problem to deeide whether a 
global theorem link holds in a development graph with hiding over FOL is not 
reeursively enumerable. Thus, any reeursively axiomatized ealeulus for devel- 
opment graphs with hiding is ineomplete. 




IV:4.5 Soundness and Completeness 309 



Proof. This can be seen as follows. Let U be the FOL-signature with a sort nat 
and operations for zero and successor, addition and multiplication. Consider 
the axiom set consisting of the usual second-order Peano axioms characterizing 
the natural numbers uniquely up to isomorphism, plus the dehning axioms for 
addition and multiplication. Without loss of generality, we can assume that 
these axioms are combined into a single axiom of the form 

VP : pred(nat) . p 

where (p is a hrst-order formula. Let be any sentence over U. Let 0: U ^ U' 
add a predicate P : pred{nat) to U. Consider the development graph 

Peano < ^ PeanoDef 

II ^ 

II id 

V 

p 

where U and Peano are nodes with signature U and no local axioms, whereas 
PeanoDee is a node with signature U' and local axiom p ^ fj. 

id 

Now we have that Peano = = ^ P holds iff each P-model has a Pean- 
oDEE-expansion. It is easy to see that this holds iff the second-order formula 
3P : pred(nat).p ^ is valid. This is equivalent to (VP : pred(nat) .p) 
i.e. equivalent to the fact that ip holds in the second-order axiomatization of 
Peano arithmetic. By Godels incompleteness theorem, the problem to decide 
whether this holds is not recursively enumerable. □ 

In spite of this negative result, there is still the question of a relative 
completeness w.r.t. a given oracle deciding conservative extensions. Such a 
completeness result has been proved by Borzyszkowski [7] in a similar setting. 
We are going to state an analogous result here, which additionally is based 
on oracles for freeness (the latter has not been covered by Borzyszkowski). 

An oracle for conservative extensions is a sound logic-specihc rule that 
allows to infer conservativity annotations for global dehnition links. It is called 
complete if for any global dehnition links that enjoys the model expansion 
property, the conservativity annotation may actually be inferred. 

An oracle for free theorem links is a sound logic-specihc rule that allows 
to infer free theorem links. It is called complete if any free theorem link that 
semantically holds also can be inferred by the rule. 

An elimination oracle for free definition links is a sound logic-specihc rule 
of the form 



0 = = 
0 = = 



where O = = ^ N is arbitrary and K is constructed out of N such that K 
does not contain any directly or indirectly ingoing free dehnition links. Here, 
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soundness just means Mod(A^) C Mod(i^). Such a rule is called complete^ if 
also Mod(it^) C Mod(A^). 

Theorem 4.19 (Completeness). Assume that the underlying logie is eom- 
plete. Then the rule system for development graphs with hiding is eomplete 
relative to eomplete oraeles for eonservative extensions and free theorem links 
and a eomplete elimination oraele for free definition links. 

Proof See [44]. 

□ 

Corollary 4.20. If the underlying logie is eomplete, the simple struetural 
rules are eomplete for proving theorem links between flattenable nodes. 

Proof. See [44]. □ 

We should note that a complete oracle for conservative extensions is very 
powerful: it can be used to obtain a complete proof calculus for development 
graphs. Namely, in order to decide whether VQ \= O = = ^ we just add a 
node P with 

O N 



P 





%d 

and ask the oracle whether N > P is conservative. 

Nevertheless, our completeness theorem is still meaningful. This is because 
the completeness proof uses the oracle for conservative extensions only in a 
limited way. The extensions considered are those obtained from hiding the- 
orem links in the development graph (pushed along some morphism into a 
‘big’ signature collecting everything). This means, for example, if we use hid- 
ing links only to hide symbols that have been dehned using some logic-specihc 
dehnition scheme, we will need the oracle for conservative extensions only for 
checking this dehnition scheme. This will be important in the next section. 



4.6 Checking Conservativity and Preeness 

Casl has annotations expressing that an extension of a specihcation is eonser- 
vative, monomorphie or definitional, meaning that every model of the ‘small’ 
specihcation can be expanded to some model, some model unique up to iso- 
morphism, or some unique model, of the ‘large’ specihcation, respectively. 
Moreover, as can be seen from the calculus studied in the previous sections, 
checks for conservative extensions already arise from the presence of hiding. 
Furthermore, during the development process, it may be desirable to check 
the specihcation for eonsisteney at an early stage - and consistency is just 
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conservativity over the empty specification. Finally, using consistency, also 
non- consequence can be checked: an axiom does not follow from a specifica- 
tion if the specification augmented by the negation of the axiom is consistent. 

So far there is no hope to tackle these questions in an institution inde- 
pendent way. Therefore, in this section we deal with the specific institution 
of Casl only. However, unfortunately already for first-order logic, neither the 
check for conservative, nor monomorphic, nor definitional extension are recur- 
sively enumerable, which means that there cannot be a complete (recursively 
axiomatized) calculus for them. For conservativity, this follows from Theo- 
rem 4.19 and the proof of Theorem 4.18: a recursively axiomatized calculus 
for conservativity would provide the needed oracle for Theorem 4.19, contra- 
dicting the example from the proof of Theorem 4.18. 

Although there is no general approach to verify that an extension of a 
specification is conservative (or monomorphic, or definitional), several schemes 
for extending specifications have been developed in the past which guarantee 
these properties by construction. We only very informally list some possible 
rules here: 

• extensions declaring new signature elements are conservative, provided the 
new symbols are not constrained in any way (by axioms, by requirements 
on the subsort and overloading relations, etc.) to be related to old symbols, 
and the new symbols themselves are constrained by a positive theory (i.e. 
not involving negation), 

• free datatypes are monomorphic extensions of the local environemnt in 
which they are introduced, 

• structured free Horn theories are monomorphic extensions, 

• subsort definitions are definitional extensions, and 

• inductive definitions over free datatypes are definitional extensions. 

There is no hope to tackle freeness in an institution independent way 
either. But is is possible to define CASL-specific oracles for free theorem links 
and elimination of free definition links. They basically introduce a new node 
that is used to mimic the quotient term algebra construction. 



4.7 Translation from Structured Specifications 
to Development Graphs 

Roughly speaking, the translation of some CASL-specification SPEC to a de- 
velopment graph works as follows: 

• it maps basic specifications, like the specification of simple abstract 
datatypes, into development graph nodes that are labelled with the signa- 
ture and the axioms of the basic specification, 

• it translates the structuring operations of Casl into definition links, and 
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• it reformulates proof obligations given in the specification either into theo- 
rem links connecting corresponding nodes or into local implications in the 
development graph. 

Obviously, the dehnition of such a translation entails the requirement to 
prove the adequacy of the translation of CASL-specihcations into development 
graphs. 

We hrst informally explain how the transformation works, using a set of 
rewrite rules shown in Figs. 4.1, 4.2 and 4.3. To translate a Casl construct 
one starts with a pre- development graph consisting of a node which contains 
the (not-yet translated) Casl construct. In the hgures, nodes which are not 
yet translated are represented as shaded boxes, translated nodes as circles. 

A pre-development graph is then processed by successively rewriting the 
boxes occurring in it, using the rewrite rules in Figs. 4.1, 4.2 and 4.3. These 
boxes are decomposed until one eventually arrives at a graph in which there 
are no boxes left, i.e. a development graph representation. During this process, 
boxes may be created which have in- going or out-going links. The thick arrows 
indicate how these links are inherited when such a box is rewritten. 

The formal translation is dehned by extending the static semantic rules for 
structured specihcations to a verifieation semanties. In the verihcation seman- 
tics, signatures are replaced with nodes in a global development graph, where 
the latter is being carried around as an additional parameter. The intention 
is that the development graph captures the semantics of the specihcation, 
while a set of theorem links over this graph captures the proof obligations 
that have to be discharged in order to ensure that the model semantics suc- 
ceeds. Note that in this point the verihcation semantics goes beyond the aims 
of the extended static semantics for architectural specihcations introduced in 
Sect. 111:5.6: the latter captures the sharing arising in architectural specihca- 
tions, but not the model semantics of specihcations. A verihcation semantics 
for architectural specihcation will be sketched in Chap. 6. 



4.7.1 Concepts for the Verification Semantics 

We now modify a number of concepts from the static semantics of structured 
specihcation (Sect. 111:4.1.5). Basically, signatures are replaced with nodes 
in a development graph. By abuse of language, a pair {VQ^ Th)^ with VQ 
a development graph and Th a set of theorem links over VQ^ is called a 
development graph as well. It will be always clear from the context whether 
a development graph comes with a set of theorem links or not. 

A verifieation generie signature GSg over a development graph consists of 
two nodes (the import and the body) and a sequence of nodes (the formal 
parameters) in the development graph. 



GSs G VerGenSig = Node x FinSeq{Node) x Node 
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SP with SM 



SP. then %cons SB 



SP then %mono SR 



5/j then %def 5^ 



S/? then % implies 5/i 



sigma(SYs) 



SR. and ... and SF ■ 

1 m J * 




KJ 












\ 

then,.. IhenS/^^^ H 


► > ♦■Q-*- 


-► 





Notation: 

f — \ 

SP CASL specification to be translated 
/ 

development graph node named SN 
.. rewrites to ... 



flow of the local environment 
— ► global definition link 
global theorem link 
— ► hiding link 



Fig. 4.1. Translating Casl specifications into development graphs with hiding 
part 1: translations, reductions, unions and extensions 
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Fig. 4.3. Translating Casl specifications into development graphs with hiding, 
part 3: views 

The requirement on a generic signature GSg = {Nj, {Ni, . . . , Nb) 
over a development graph {VQ^ Th) is that all the nodes involved in GSs are 
contained in {VQ, Th)^ and that 
strip{GSs) = 

is indeed an (ordinary) generic signature in the sense of Sect. 111:4.1.5. 

The notion of compatibility between signatures and models can be carried 
over: given an element GS^ = i M.m) ^ M.b) of GenSpec (cf. 

Sect. 111:4.1.5) and a verification generic signature GS s = (A/"/, (A^i, . . . , A^n), 
Nb) over a development graph (VQ^ Th)^ we say that GSg and GSm are 
compatible^ if 
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• m = 

• Modpg (A^/) = Ad/, 

• Modpg(A^^) = Ad^ (z = 1, . . . , n), and 

• 'M.odjyg^NB) = Ad^. 

A verification view signature consists of a node (the source node), a signa- 
ture morphism, and a verihcation generic signature (the target of the view). 

Vs G VerViewSig = Node x SignatureMorphism x VerGenSig 

For a verihcation view signature Vs = {Ns^cr^ GS s) in VerViewSig over a 
development graph (VQ^ Th)^ we require that all the nodes involved in Vs are 
contained in {VQ, Th)^ and that 

strip(Vs) = strip{GS s)) 

is an element of ViewSig as dehned in Sect. 111:4.1.5. 

Given an element V^ = (Adg, GS^) of View'Spec and a verihcation view 
signature Vs = (A^s, a, GSs) over a development graph {VQ, Th)^ we say that 
Vs and Vm are compatible^ if 

• Modpg(A^5) = Ads, 

• = (iV/,(iVi,...,iVn),A^B) and GS^ = (Ad/, (Adi, . . . , Ad^), Ad^) 
are compatible, and 

• Msla^Ms. 

We now come to verihcation global environments. Apart from the usual 
global environment components (cf. Sect. 111:6.1), these need to carry around 
a global development graph together with a set of theorem links over this 
graph. This is necessary in order to achieve the intended sharing between 
different instantiations of one and the same generic specihcation. The global 
development graph is successively extended by the rules for specihcations. 
This hnally leads to an update of the global development graph in the rules for 
specihcation and view dehnitions. We also assume that the global development 
graph always contains a node named 0 which consists of the empty signature 
and the empty set of axioms. 

A verification global environment 

{vg, Th) = (0„ As^Ts), {vg, Th) 

consists of a development graph (Vg^ Th) and hnite functions from names 
to the verification denotations of generic specihcations, views, architectural 
specihcations and unit specihcations (cf. Chap. III:6): 

• 05 : SpecName ^ VerGenSig 

• Vs : View Name ^ VerViewSig 

• As : ArchSpecName ^ VerArchSig 

• Ts : UnitSpecName ^ VerUnitSig 
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The domains VerGenSig and VerViewSig have been defined above, while 
VerArchSig and VerUnitSig will be defined in Chap. 6 . 

Requirements on a verification global environment (^ 5 , Vs, w4g, 7^), 
(VQ^ Th): the domains of the various components are disjoint {Qs, Vs, w4s, 7^), 
and each involved verification signature (i.e. verification generic signature, 
verification view signature etc.) is well- formed over {'DQ^ Th). 

Both the stripping operations and the compatibility relation extend to 
global environments in a pointwise way (domains of compatible environments 
have to be equal). 

In the rules below, we often use the notation and ^ which of course 
only makes sense only relative to a given development graph. Which devel- 
opment graph is meant can be seen from the descriptions of the formats of 
the judgements: there, for each node the development graph it lives in is men- 
tioned. Moreover, the development graphs occurring in a rule are all extensions 
of another, such that any of them can be equally chosen to compute and 

^ as long as N is contained in the graph. 

We say that a development graph VQ' extends a development graph VQ if 
VQ is a subgraph of VQ' in the obvious sense. Moreover, we say that a family 
of development graphs VQi^ i ^ I (for an arbitrary index set I) disjointly 
extends VQ if each VQi extends VQ (for i ^ I) and moreover, for all distinct 
z, j G 7, VQi n VQj = VQ. If this is the case, then the union [J^^jVQi is 
well-defined and extends VQ. 

Whenever such a disjointness requirement appears in the rules below, in 
principle it could be eliminated by appropriate choices of new names. However, 
spelling this out would only add uninteresting detail, which we omit here and 
state the disjointness requirement explicitly. 

In the verification semantics, we use judgements of form 

eontext h phrase result. 

We will rely on notions and judgements (of form eontext h phrase > result) 
of the static semantics of structured specifications, which the reader should 
consult whenever necessary (Chap. III:4). 

For readability, the definition and theorem links are decorated with U ^ 
U' whenever tzicu' is meant (which of course assumes that U C U'). 



4.7.2 Structured Specifications 



N, Ts, {VQ, Th) h SPEC N', {VQ' , Th) 

Tg, {VQ, Th) is a verification global environment, is a node in VQ; then 
{VQ' , Th') is a development graph extending {VQ, Th), N' a node in VQ' , 
and is an extension of . 
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Basic Specifications 



jjbasic |_ bASIC-SPEO 

^ (^jjbasic^ g^<Y) S' = U Zi, SSY U \A\) 

N, Fs, (vg, Th) h BASIC-SPEC qua SPEC ce^ 

N', {vg W {N' with (S', '!')■ N A^'}, Th) 



Translations 



N,Fs, (vg, Th) h SPEC cg^ TV', (vg', Th') 

\- RENAMING > a : E^' E" 

|(j| is the identity on signature symbols in |iT-^| 

TV, Fg, {vg, Th) h translation SPEC RENAMING ce^ 

TV", {Vg' a {TV" with {E", 0); TV' TV"}, Th’) 



Reductions 



N,Fg, {vg, Th) h SPEC cg^ TV', {vg' , Th') 

{E^, E^') h RESTRICTION txr: Ei^E" 
vg" = Vg'M^{ TVi with (dTi, 0); TV" with {E" , 0); 

y-i y-iTV^ 

TV' \ ^A^i; A^i^^TV"} 

hide 

TV, Fg, (vg, Th) h reduction SPEC RESTRICTION gg^ TV", {Vg" , Th') 

Unions 

TV, Fg, {Vg, Th) h SPECi gg^ TVi, (D^i, Thi) 

TV, Fg, {vg, Th) h SPEC„ gg^ Tv„, {vg„, Th„) 

E' = U . . . U E^”- 
Vgi, . . . , Vg„ disjointly extend Vg 

T>g' = U =1 „ Tigi a (A^' with {E', 0)} a { Nt=^N'\i = 1, . . . , n} 

Th' = Thi 

TV, Fg, {Vg, Th) h union SPECi . . . SPEC„ gg^ TV', {Vg' , E' , Th') 

Extensions 



TV, Fg, {vg, Th) h SPECi gg^ TVi, (H^i, Thi) 

N„_i,Fg, {vg„-i, Th„-i) h SPEC„ gg^ N„, {vg„, Th„) 

TV, Fg, {vg, Th) h extension SPECi . . . SPEC„ ggg> TV„, {Vg„, Th„) 
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Moreover, for each extension from SPEQ_i to SPEQ that has been an- 
notated to be conservative, monomorphic, or definitional, a proof obliga- 



tion = = = = = ^ N,, N,_i = = = = = ^N, 

t ± rnriQ i i. mnmn ^ 



Ni-i^ = = =^=- 
def 



■Ni. 



respectively, should be added to T/ij. (Note that Casl requires that sym- 
bols from the local environment must not be affected by hidings; therefore, 

we always have C and even Ni-\ = = = = = ^ Ni can easily be 

seen to hold.) Finally, for an extension from SPEQ_i to SPEQ that has been 

annotated to be implied, a proof obligation Ni = =%> Ni-i is added (note that 
for such an annotation, is required). In the case that the exten- 

sion from SPEQ-i to SPEQ is simply a basic specification, a proof obligation 
Ni-i ^ suffices instead (but note that in general, SPEQ may involve 
hiding etc.). 



Free Specifications 



N, n, {vg, Th) h SPEC N', (vg', Th') 

N, Fs, {vg, Th) h free-spec SPEC 

/ ^ c ^ ^ 

N", iVg' a {N” with , 0); N' > N”}, Th') 

free 



Local Specifications 



N, r„ {vg, Th) h SPEC N', {vg', Th') 

N', r^, (vg', Th') h SPEC’ cg^ N", (vg", Th") 

El = \ \^N'\ c iril 

N,Ts, {Vg, Th) h local-spec SPEC SPEC’ 

N’", {Vg" a {N'" with (ri, 0); TV" ' . )> N'"}, Th") 



Closed Specifications 



0, Fs, (Vg, Th) h SPEC N', {Vg', Th') 
E" = LI E^' 



vg" 



= vg' y {N" with {F", 0); N > N"; N' > N"} 

N, Fg, {vg, Th) h closed-spec SPEC N" , {Vg" , Th U Th') 
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4.7.3 Named and Generic Specifications 
Specification Definitions 

Ts, {T>g, Th) h SPEC-DEFN Tj, {VQ\ Th') 

Fs, {F>Q, Th) is a verification global environment; then F!,, {T>Q' , Th') is a ver- 
ification global environment extending Fg, {VQ, Th). 

-Ts = {Gs,Vs,As,'Ts) 

SN ^ dom Os U dom Vj U dom Ag U dom Tg 
Fg h GENERICITYce^ (A^/, {Ni, . . . , Nn), Np), {Vg p, Thp) 

Npj -C, {T>g p, Thp) h SPEC Cgg> (T^g Thp) 

Fg, {Vg, Th) h spec-defn SN GENERICITY SPEC 

{gg U {SN ^ (Ni, (N^,.. .,N„),NB)},Vg,Ag,Tg), (Vgs, Thp) 

Genericity: Parameters and Imports 



Fg,{Vg, Th) h GENERICITY {Np {Ni, . . . , Nn) , Np), {Vg p, Thp) 

Fg, (vg, Th) is a verification global environment; then (Vgp, Thp) is a de- 
velopment graph extending (Vg, Th), Nj, Np and the Ni are nodes in Vgp, 
such that is an extension of , and is the union of the F^' 

(i = l,...,n). 



Fg h IMPORTS Nj, (vg, Th) 

NpFg, (Vg, Th) h PARAMSce^ {Ni, . . . , Nn), (Vg p, Thp) n > 1 
Fp = F^^ U---U F^- 

vg'p = Vgp\i}{Np with (rp,0)}a{Ar^ ^ ^A^p | i = 

Fg, (Vg, Th) genericity PARAMS IMPORTS 

{Ni,{Nu...,Nn),Np),{Vg'p,Thp) 

Vg = (gg,Vg, As,Fg) 

Fg \- IMPORTS 0, (vg, Th) 

0, Fg, (Vg, Th) h PARAMS (), (Vg, Th) 

Fg, (Vg, Th) h genericity PARAMS IMPORTS (0, (), 0), (Vg, Th) 



Parameters 



NpFg, (vg, Th) h PARAMS (A^i, . . . , Af„), (Vgp, Thp) 

Fg, (vg, Th) is a verification global environment and Nj is a node in Vg-, then 
(vgp, Thp) is a development graph extending (Vg, Th), the Ni are nodes in 
vgp (i = 1, . . . ,n), and F^' is an extension of F^‘ for 1 < i < n. 
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Ni,Ts, {vg, Th) h SPECi Ni, {VQi, Thi) 

Ni.Fs, {Vg, Th) h SPEC^ Nn, (VQn, Thn) 

VQi^ . . . , VQn disjointly extend VQ 
Nj^Ts^ {Vg^ Th) h params SPECi . . . SPEC^ 

(TVi, . . . , iV„), U=i...,„ r/ro 



Imports 



Ts, {Vg, Th) h IMPORTS N, {Vg' , Th') 

Tg, {T>g, Th) is a verification global environment; then {T>g\ Th') a develop- 
ment graph extending {Vg^ Th) and is a node in Vg' . 

If the sequence of imported specifications is empty, then the semantics of 
the import construct is the empty environment 0, and the development graph 
is from the global environment not extended but just retained. 



Tg, {T>g, Th) h imports 0, {Vg, Th) 



^,Tg,{Vg, Th) h union SPECi ... SPEC^ Thi) 

^ ^ Empty Explicit I )CE^ I 

Tg, {vg, Th) h imports SPECi . . . SPEC^ 

N, {Vgi y {N with {EmptyExplicit{U^^), 0); Np N}, Thj) 



Specification Instantiation 

We repeat the rule format for structured specifications: 



N, Eg, {Vg, Th) h SPEC N', {Vg', Th) 



Eg, {vg, Th) is a verification global environment, is a node in Vg; then 
{vg' , Th') is a development graph extending {Vg, Th), N' a node in Vg' , 
and is an extension of . 



vg' 



gg{SN) = {^,{),NB)) 

{N'with{E^UE^-,^y, 7V/= 






N'} 



N, Eg, {Vg, Th) h spec-inst SN N', {Vg' , Th) 
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g^iSN) = GS, = {Ni, {Ni,..., Nn), Nb) n > 1 
Ni,Ni,Ts, {Vg, Th) h FIT-ARGi m> ai,N^ ,{Vgi, Thi) 



Ni, Nn, r„ {Vg, Th) h FIT-ARG„ cr„, {Vg„, Th„) 
{S',crf) = strip{GSs){{S^^ ,(7i), . . . , ,an)) is defined® 

VQi^ . . . , VQn disjointly extend VQ 

^'i — ^Z'CZ^UZ' ^ (^ = 1, . . . , 

T^Q' = U= 1 ,...,„ with (r^ u S', 0)} 



'S{N-- 



•TV'; Nb = 
■ TV' I i = 1, . . . , n} 



■TV'} 



TV, Ts, {vg, Th) h spec-inst SN FIT-ARGi . . . FIT-ARG„ ce^ 

N',{Vg',\Ji=i,...,nThi) 



Fitting Arguments 



Ni, Np, Fs, {Vg, Th) h FIT-ARG a, Na, {W , Th') 

Fg, {FQ, Th) is a verification global environment and Nj and Np are nodes in 
vg such that is an extension of then {Fg' , Th') is a development 
graph extending {Fg, Th), Na is a node in Fg' such that F^^ is an extension 
of F^^ , and a is a signature morphism from F^^ to F^^ which is the identity 
on F^F 



Ni, Fg, {Fg, Th) h SPEC Na, {Fg' , Th') 
h SYMB-MAP- ITEMS* > r 
a = a is the identity on F^^ 

Ni, Np, Fg, {Fg, Th) h fit-spec SPEC SYMB-MAP- ITEMS* 

a, Na, {Fg', Th'u{Np = = ^ Na}) 



4.7.4 Views 
View Definitions 



Fg, {Fg, Th) h VIEW-DEFN F^, {Fg' , Th') 

Fg, {Fg, Th) is a verihcation global environment; then F^, {Fg' , Th') is a ver- 
ihcation global environment extending Fg, {Fg, Th). 



® See Sect. 111:4.1.5 for an explanation of the notation GSg{- • •)• 
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Cs = (Qs,Vs,As,Ts) 

VN ^ dom Vs U dom Qs U dom As U dom 'Tg 
rs,iVg, Th) h GENERICITY (TVj, (TVi, . . . , 7V„), TVp), Thp) 

Np,r.s, {vgp, Thp) h VIEW-TYPE (Vs, V(), [Vg' , Th') 

I- SYMB-MAP- ITEMS* t> r a = 

V( = Vs u { vv ^ (Ns, a, (Ni, (Vi, . . . , N„), Nt))} 

Ts, {Vg, Th) h view-defn VN GENERICITY VIEW-TYPE SYHB-HAP-ITEMS* 

(Qs, Vs, A, Ts), (Vg', Th'u{Ns= = ^ Nt}) 



View Types 



N, Ts, {Vg, Th) h VIEW-TYPE t:8^ {Ng, Nt), {Vg' , Th') 

Tg, {T>g, Th) is a verification global environment and V is a node in Vg-, then 
{vg' , Th') is a development graph extending {Vg, Th), Ng and Nt are nodes 
in vg' , and the signature is an extension of . 



0, Vg, {vg, Th) h spECi Ng, {vg', Th') 

N, Tg, {Vg', Th') h SPEC 2 Nt, {Vg" , Th") 

N,Tg, {vg, Th) h view-type SPECi SPEC2 ceg> {Ng,Nt), {Vg" , Th") 

Fitting Views 

We repeat the rule format for fitting arguments: 



Ni, Np, Tg, {Vg, Th) h FIT-ARG a, Na, {Vg', Th') 

Tg, {vg, Th) is a verification global environment and Nj and Np are nodes in 
vg such that is an extension of then {Vg' , Th') is a development 
graph extending {Vg, Th), Na is a node in Vg' such that is an extension 
of , and ci is a signature morphism from to E^^ which is the identity 
on E^V 



Vg = {gg,Vg,Ag,Tg) Vg{VN) = (Vs, a, (0,0, Vt))) 

jjNs u jjN, ^ jjNp 

vg' = vg w{Va with {e^‘} u v^*,0)} 






W{Vj 
W{V' with (r^^’,0)} 



W{Vj 



Na; Nt 

)} 

N'; Ng 



E‘^iUE‘ 












Na} 

N'} 



Ni,Np,Tg,{Vg, Th) h fit-view VN CK> 

a U ids, , Na, {Vg', Tht U { Vp = V'}) 
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- - 

N' ^ :^Ni^ ^ Na 

k 
id I 
I 

Np 

Fig. 4.4. Non-generic fitting views: relation between sigantures of nodes 



Note that the import Nj is already included in Np. 



p = {g„V,,As,%) VdVN) = {N„a, GS,)) 

U = ENp 

GS, = {N'j,{Ni,...,N„),Nb) n>l 
N'j, Ni,P, {Vg, Th) h FIT-ARGi TVi^, Thi) 

N'j, Nn, Fs, {Vg, Th) h FIT-ARG„ a„, N^, {Vgn, Thn) 

{Ea,(j'j:) = strip{GS s){{E^^ jCri), . . . , {E^'^ is defined 

= ^Z’aCZ’^/UZ’a ° 

VQi^ . . . , VQn disjointly extend VQ 

D0'=DawU=i....,n250i 

a {Va with {E^’ yjEA,%)} 



a {N‘- 

a{v^ 



■Na\ Ne 



■Na} 



^U^iuUa 



NA\i = l,...,n} 



a {N' with (r^^,0)} 



a {Ni 






>N'-, Ns 






N'} 



Ni,Np,rs, (F>g, Th) h fit-view VN FIT-ARGi . . ,FIT-ARG„ ce^ 

{a} O a) U id^M, , Na, ivg' , Thi U { Vp = = ^ TV'}) 



4.7.5 Adequacy of the Translation 

In order to be useful, the translation of Casl specihcations to development 
graphs has to satisfy appropriate adequacy theorems. 

Theorem 4.21. Let a static global environment Fg and a verification global 
environment Tj, {VQ ^ Th) with strip{Ffi {VQ ^ Th)) = Fg and a node N in VQ 
be given. If 

E^,P h SPEC> V, 
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N' ^ ^ Na 



k 
id I 
I 

Np 



Fig. 4.5. Generic fitting views: relation between sigantures of nodes 

then 

N, r', ivg, Th) h SPEC N', ivg', Th') 

for some {T>g\ Th'), with = U' in Vg' . Viee versa, if 

N, r', {vg, Th) h SPEC N', (vg', Th') 

then 

U^,Ts hSPEOi:^', 

Moreover, in either of these equivalent eases, given a model global environment 
Tjn eompatible with Tj, {T>g, Th) and furthermore given a elass of -models 
A4, the following are equivalent: 

1. there is a model elass M.' with U, Mi, Tg, T^ \~ SPEC ^ A4' . 

2. vg' h Th", 

where Th" C Th' eontains those theorem links not generated by semantie 
annotations^. Furthermore, if these two equivalent eonditions hold, then 

M' = {M e Modp,g^{N') I M\jje M}. 

The proof of this theorem follows an induction over the rules for the ver- 
ification semantics. The theorem states that the verification semantics, when 
the development graph information is stripped off, does the same as the static 

^ In the sequel, we will tacitly assume that the theorem links corresponding to 
semantic annotations are removed from the set of theorem links - only then, the 
model-theoretic semantics is captured. On the other hand, usually one will keep 
these theorem links as proof obligations, since once they are proven, they provide 
further trust in the specification. 
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semantics. Moreover, the extra development graph information (most impor- 
tantly, the theorem links Th that capture the proof obligations) constructed 
by the verihcation semantics is sufficient to capture the model semantics. 

Note that the verihcation global environment {FQ, Th) in the above 
theorem usually will be obtained from the verihcation semantics of libraries, 
see Chap. 6. 

We now reformulate consequences of and rehnements between Casl struc- 
tured specihcations in terms of development graphs. 

Definition 4.22. Consider a static global environment Fg = (^s. Vs, Ms, 7^), 
compatible with some model global environment Fj^. Let 0) be 

the trivial verification global environment with strip{F^^'^'^) = Fg, that is, in 
ppgtriv ^ /or each ocurrence of signature being part of a generic signature in 
Dom{Qg) or of a view signature in Dom{Vg), a new node with that signature 
and no local axioms is introduced, = (^',V 5 , 0 , 0 ) is such that maps 

each SN C Dom{Qg) to the verification signature obtained from the generic 
static signature Qg{SN) by replacing the signatures with the corresponding 
nodes, andVg is obtained similarly. Obviously, ,tj)) is compatible 

with Fjn CLS well. 

Consider now Casl structured specifications SPEC, SPECi and SPEC 2 . If 

^,Fg h SPEO i:, 

and F is a set of F- sentences, then 

rs,r^: SPEC 

is defined to mean that Fg, Fj^ k SPEC ^ A4, and M \= F for each 

M C At. By Theorem 4-21, we have 

0, 0) h SPEC N, {vg\ Th') 

for some N and {VQ' , Th'). We write 

Fg : SPEC h F 
for 

vg' h N ^ F. 



Furthermore, if 

0, Fg h SPECi > i: and 0, Fg h SPEC 2 > 

then 

Fg,Fm: SPECi ^SPEC2 

is defined to mean that (/), A4±, Fg, F^ k SPECi ^ Ati and (/), A4±, Fg, F^ k 
SPEC2 ^ At2; for some model classes Ati and M.2 such that M.2 C Ati. By 
Theorem 4-21, 
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0 , rl™, h SPECi t: 8 ^ Ni, {vg\ Th'), and 

0 , rf {vg\ Th') h SPEC2 N2, (vg", Th”) 



for some {Vg' , Th'), {Vg” , Th”), Ni and N 2 with 
write 



Fs : SPECi SPEC2 



JjN2 _ JJ ^ 



for 

vg” h 7Vi = = ^ N2- 

Using Theorem 4.17, we now obtain 

Proposition 4.23. Inference for structured specifications is sound as well, 
that is, given a static global environment Fg, 



Fs : SPEC h F 



implies 

for each F^ compatible with Fg, it holds that Fg,Fm : SPEC ^ F] 

and 

Fg : SPECi SPEC2 

implies 

for each Fm compatible with Fg, it holds that Fg,Fm : SPECi ^SPEC2- 



□ 



With Theorem 4.19, we obtain 

Proposition 4.24. Assume that the underlying logic is complete. Then in- 
ference for structured specifications is complete relative to complete oracles 
for conservative extensions and free theorem links and a complete elimination 
rule for free definition links, that is, given a static global environment Fg, 

for each compatible with Fg, it holds that Fg,Fm : SPEC ^ F 



implies 



and 



Fg : SPEC h F; 



for each compatible with Fg, it holds that Fg,Fm : SPECi ^SPEC2 



implies 



Fg : SPECi SPEC2. 



□ 
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Remark 4-25. The proof-theoretic notions of consequence and rehnement for 
Casl structured specihcations have been introduced above with reference to 
the trivial verihcation global environment. This is quite restrictive (since it 
disallows the use of the properties of those specihcations and views used which 
have been dehned externally) but can be generalised to the case of an arbitrary 
verihcation global environment used to describe the specihcation and view 
names that the specihcations in question use. Props. 4.23 and 4.24 hold then 
for global model environments that are compatible with verihcation global 
environments made explicit in such a way. 

Remark 4-26. In Sect. 5.3.1 of the architectural proof calculus, there appear 
conditions of the form 

t]{R(SPEC)) U T]i(R{SPECi)) 

where rji^ r] are signature morphisms with common target signature R is 
the action of the global comorphism given by the general assumption made in 
Remark 4.3 on structured specihcations, and R adds the sentences resulting 
from signature translations (see Sect. 5.3.1 for formal dehnitions of the latter 
two)^^. 

In the context above, this can be interpreted as follows. We take the needed 
runs of the verihcation semantics: 

0, r*™, h SPEC O, {vg^, Tho), and 

0,^y^ {vgi-i, Thi-i) h SPEQ Oi, (vgi, Th). 
Well-formedness of the involved specihcations is captured by 

VQn ^ Thn^ 

In order to interpret the proof obligation, take the translation R{DQn) of VQ^ 
along R. Now take 

vg’ = R{vgn) w {A^I with (r,0); N 2 with (r,0); R{0) Ni} 
U{R{Oi)^^N 2 I i = l...n} 

Then 

»y(J?(SPEC)) IJ 7J,(R{SPEC,)) 

i=l...n 

just means that 

vg' h Ni= = ^ N2- 



10 



In Chap. 5, hnite sets of specihcations and their translations are considered. 
However, these can be replaced with their Casl unions. 




5 



Architectural Specification Calculus 



In this chapter we consider the problem of proving that a given architectural 
specihcation has a denotation (i.e., is correct) and that the units produced 
using it satisfy a given unit specihcation. In order to make the presentation 
readable we deal with a slightly restricted language of architectural specih- 
cations (Fig. 5.1). For the same reason we prefer to use a concrete syntax 
instead of the abstract one (the reduction construct represents both hide 
and reveal), and to assume that signature morphisms are explicit elements of 
the syntax, which frees us from introducing the notions of symbol and symbol 
map. 

ASP ::= units UDi . . . UDn result UE 
UD ::= A : USP 
USP ::= SP I 

SP SP 
UE ::= UT \ 

\ A: SP%UT 
UT v= A\ 

A[UT fit (T : E ^ E' ] \ 

UT and UT \ 

UT with G \ E ^ E' I 

UT reduction g \ E ^ E' \ 
local A = UT within UT 

Fig. 5.1. Restricted language of architectural specihcations. 



Thus, we do not take the following features of Casl architectural specih- 
cations into account: 

• imports (the given construct); 

• multiparameter units; 

• complex forms of unit specihcations (using local or global environments); 

• local dehnitions of generic units; 

• dehnitions mixed with declarations. 

Of the above only imports add genuine complexity to the proof calculus. 
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5.1 Semantics 



In this section we will give the static, model, and extended static semantics for 
the restricted language of architectural specifications presented above; we also 
introduce many concepts that we then expand in Sect. 5.3, which presents the 
proof calculus. This section may serve not only as a necessary preliminary for 
the subsequent sections, but also as a less formal introduction to Chap. III:5, 
with which it is fully consistent. We take concepts such as signature inclusion, 
as defined in Chap. III:4, for granted. We also assume that the signature 
category of the underlying institution has selected pushouts; for Casl, they 
have been defined in Sect. 111:4.1.3. 



5.1.1 Static and Model Semantics 

By a unit signature UU we understand either a (regular) signature or a 
generic unit signature U ^ U' ^ where is a subsignature of U' . By Unit(bW) 

we denote the class of all units over bW, i.e., Unit(i7) = Mod(i7) and 
Unit(i7 ^ is the set of all partial functions F : Mod(i7) ^ Mod(i7') 
which are persistent^ that is, F{M)\jj = M for all M C dom(F). 

In this chapter unit names will be denoted by the letters f/, A, and 
so on. A static context Cg assigns unit signatures to a finite number of unit 
names. An environment E fitting Cg assigns an element of Unit((C 5 (f/)) to any 
unit name U G dom{Cg). A context C fitting Cg is any class of environments 
fitting Cg. A model evaluator MEv from C to E is simply a function from C 
to Mod(i7). Similarly, a unit evaluator UEv from C to UE is a function from 
C to Unit(bW). In the semantics, by Ad we will denote classes of models over 
a common signature, and by lA classes of units over a common unit signature. 

We assume that for any specification SP the semantics defines a signature 
sig[SP] and a class of models {SP} C Mod(5Z5r[/S!P]). Thus we disregard any 
(purely technical) problems arising from incorrect specifications or from local 
environments. We say that SP SP' is a generic unit specification if sig[SP] 
is a subsignature of sig[SP']; such a specification defines the class of units 
{SP SP'}^ containing all units F G Unit {sig[SP] sig[SP']) such that 

dom(F) = {SPj and for all M G dom(F) we have F{M) G |/SP']. A specifica- 
tion SP is inconsistent if {SP} = 0; a generic unit specification SP SP' is 
inconsistent if [SP SP'} = 0. 

The static (using >) and model (using ^) semantics may be presented by 
the following rules. It is assumed that the model semantics will be run only 
after a successful run of the static semantics. 
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h ASP > Cs, UP h ASP => UEv 

The context dom{UEv) fits Cg and UEv is a unit evaluator into UP. 



h UDi t> Cl 
h UD^ t> C” 

dom(C*) n dom(C| ) = 0foralll<i<j<n 

c, = c 1 u ■ ■ ■ u C” 

Cs^UE\> US 

h units UDi . . . UDn result UE > (V5, UP 
h UDi > Cl h UDi => C^ 

h UD„ >C^ h UD„ => C" 

C, = C 1 U ■ ■ ■ U C” 

C = {EiU---UEn\EieC\...,E„eC’^} 
C„ C\-UE^ UEv 

h units UDi . . . UDn result UE => UEv 



hUD>Cs hUD^C 

The context C fits Cs- 



\- A: SP \> {A^ s*5[SP] } 

h A: SP ^ {{A^ M}\M e [SP] } 

sig[SP] is a subsignature of sig[SP'] 
h A: SP ^ SP' \> {A^ sig[SP] sig[SP'] } 



h A: SP ^ SP' ^ {{A^ F}\F elSP ^ SP'] } 
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C,hUE>UE C,,ChUE ^UEv 

The context C should fit Cg. Then UEv is a unit evaluator from C to UE. 

CghUTt> E 
Cg h UT qua UE \> E 

Cg, ChUT^MEv 
Cg,C'rUT qua UE ^ MEv 

A ^ dom(Cs) 

Cg\J{A^ sig[SP] }hUT\> E 
sig[SP] is a subsignature of E 

Cgh \A: SP • UP \> sig[SP] E 
Cg\j{A^ st5[-SP]} 'rUTt> E 

Cgyj{A^ szff[SP]}, {Eyj{A^ M)\E aC,M e [SP] }'rUT^ MEv 
for all P e C and M G |5!P] we have MEv{E U {A M})\gig[sp] = M 

Cg, C h XA : SP •UT ^ XE e C ■ XM e [SP] ■ MEv{E U{A^ M}) 



CghUT>E Cg,C^UT^ MEv 

The context C should fit Cg. Then MEv is a model evaluator from C to E. 



Cg{A) = E 
Cg'r A> E 



Cg,C^ A^XE eC ■ E{A) 

Cg{A) = Ef^Er 
Cg^UT>Ea 

T : Ea ^ A and a' : Ey ^ A form the selected pushout for (cr, iEjQSr) 
Cg'r A[UT m. a : Ef ^ Ea]> A 
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Cs.ChUT^ MEv 
for all E eC, MEv{E)\^ G dom(^(A)) 

= Ef^Er 

T : Ea ^ A and a' : ^ A form the selected pushout for (a, 

for diW E e C there exists a unique Z\-model Me such 
that Me\t = MEv{E) and = E{A){MEv{E)\^) 

Cs,Ch A[UT m a: Ef ^ Ea]^ XE eC^ME 



Cs^UTi> El 

CshUE2t> E 2 

Cs UTi and UT 2 > EiVJ E 2 

Cs^UTi\> El 
Cs^UT2\> E 2 
Cs, C^UTi^ MEvi 
Cs, ChUT2^ MEv2 
E = El U E2 

for all E” G (V there exists a unique V-model Me such 
that Me\e\ — MEvii^E') and Me\e 2 ~ MEv2{E') 

Cs, ChUTi andUT2^ XE eC ^ Me 

CshUT> E 

CshUT with a : V ^ V' > V' 

Cs,ChUT^ MEv 

for all E” G (V there exists a unique V'-model Me such that Me\(t = MEv{E) 
Cs,C^UT with a : E ^ E' ^ XE e C ^ Me 

Cs^UT> E^ 

Cs UT reduction a : E ^ E' \> E 
Cs,ChUT^ MEv 

Cs,ChUT reduction a : E ^ E' ^ XE e C • MEv{E)\^ 

A ^ dom((V5) 

CshUTt> E 

CsU{A^ E}hUT' > E' 

Cs \- local A = UT within UT' \> E' 
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Cs^UT\> U 
Cs.ChUT^ MEv 

CsU{A^ E}, {EU {A ^ MEv{E)} \E eC}hUT' ^ MEv' 

Cs, C h local A = UT within UT' ^ XE e C ^ MEv'{E U{A^ MEv{E)}) 



5.1.2 Extended Static Semantics 

As has been argued in the introduction to Sect. 111:5.6, one would expect that 
the four premises of the model semantics starting with ‘dor all E ^ C. . . ”, 
found in the rules for and, with, for generic unit application and for A- 
abstraction, will be dismissed not by means of theorem-proving, but rather in 
a semi-automatic manner. This is motivated by their static nature and by the 
fact that the similar sharing conditions of languages such as Standard ML are 
checked automatically. 

Toward this end one introduces an extended static semantics^ (denoted 
using [>). It can be then proven that if ASP has a denotation (we use □ as 
the dummy denotation) w.r.t. the extended static semantics, then it has a 
denotation w.r.t. the static semantics and in the model semantics none of the 
above-mentioned 4 premises need to be checked (see Sect. 111:5.6). Using the 
extended static semantics also makes it easier to develop a proof-calculus. The 
extended static semantics presented below is essentially equivalent to that of 
Sect. 111:5.6. contexts instead of the However, in order to make the semantics 
easily extendible to a readable proof calculus, in the sequel we will be using 
contexts instead of the diagrams used there. Thanks to that, the proof-calculus 
presented in Sect. 5.3 will then be a rather straightforward extension of the 
extended static semantics. The link between ‘standard’ (i.e., static and model) 
semantics and the extended static semantics is described in the next section. 

A generic context Egen is a finite set of declarations A : E ^ E' ^ where 
E ^ E' \s a generic unit signature. 

A context T is a finite set of declarations of two forms: 

• A:E‘ 

• a : A ^ where A : Ea and B : Eb in T and a : Ea Eb is a 
signature morphism. 

Any unit name may be declared at most once in a context E ; the same applies 
to unit names in generic contexts T^en- 

By dom(T) we denote the set of unit names A such that A : E in E for 
some signature E; we define dom(T^en) analogously. If Ei and E 2 are two 
contexts and for all A G dom(Ti) ndom(/ 2 ) we have A : E in Ei if and only if 
A : U in T 2 , then their sum Ei U E 2 is a context as well. We say that a context 
T is a suhcontext of the context E' if the declarations of E form a subset of 
the declarations of E' . 

^ Extended static semantics is described in Sect. 111:5.6 and, e.g., in [62]. 
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If is a context and A, B and B' are unit names, then B[B' /B] and 
A[B^ / B] arise from B and A in the obvious way by substituting B' for B 
(that is, A[B' /B] \s A \i A^ B and it is B' \i A = B). 

A model family M = {Mt/}t/Gdom(r) is consistent with B if: 

• for all A : A in B^ we have Ma ^ Mod(A); 

• for dl\ (7 : A ^ B m B ^ we have Ma = Mb\(T’ 

Let be a subcontext of Bh We say that B ensures amalgamability for B' 
if every model family consistent with B uniquely extends to a model family 
consistent with B'. 

The rules for deriving extended static semantics statements follow. The 
general idea is that the statement A, T^en, ^ ^ bJT [> T', A expresses the fol- 
lowing fact: assume that we have a model family consistent with B - this model 
family consists of units declared in the architectural specihcation’s units sec- 
tion, of units locally dehned in it, and of ‘dummy’ units used for terms etc.; 
A is the set of names of declared or locally dehned units. Assume also that 
we have generic units as described by T^en- Then the unit described by UT 
may be built and, moreover, one may obtain it by extending the given model 
family in a unique way to a model family consistent with B' and then taking 
the unit labeled A. The symbol ‘D’ is used as a dummy denotation in cases 
where we are only interested whether for a given construct the extended static 
semantics is successful or not. 



h ASP [> □ 

htzDi 

dom(rgg„) n dom(qg„) = 0 for all 1 < i < j < n 
dom(P*) n dom(P'l) = 0 for all 1 < z < j < n 

r — u • • • u M 

r = u • • • u 

dom(T^en) n dom(T) = 0 
Bgen, B h UE [> □ 

h units UDi . . . UDn result UE [> □ 



h UD [> Bgen, B 



h A : [> {A : sig[SP]}, 0 

sig[SP] is a subsignature of sig[SP'\ 



h A : ^ [> 0, {A : sig[SP] ^ sig[SP']} 
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Fgen, F h UE [> □ 

The sets dom(T^en) and dom(T) should be disjoint. 

dom(T), Fgen, F h UT [> T', A 
Fgen , F h UT qua UE [> □ 

A ^ dom(T) U dom(r^en) 

dom(r) U {A}, Fgen, ru{A: sig[SP]} h CT [> T', 5 
B : E in F' and sig[SP] is a subsignature of E 
F' ensures amalgamability for F' U {id^; : A B} 
Fgen^I^^^^ATspVuF^B 



A, Pgen, F ^ UT F' ,A 



The inclusion A C dom(T) \ dom(T^en) should hold. Then T is a subcontext 
of F' and A e dom(T'). 



AeA 

A, Fgen, r h A [> r, A 



A : i: 



/ 



Er in F. 



gen 



A, Fgen, F^UFl^Fa.Aa 
Aa • Ea in Fa 

T : Ea ^ A and a' : Er ^ A form the selected pushout for (a, iUfCU^) 
Af^Ar^B ^ dom(iA) are distinct 
F' = FaU {Af : Ef^ a : Af ^ Aa, Ar : T’r, : Aj ^ A^} 

r" = F'U{B : A, riAa^B, a' : Ar ^ B} 

F' ensures amalgamability for T" 



A, Fgen, T h A [ UT fit a : Ef ^ Ea ] F" , B 
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-4, F h UTi [> A, 4.1 
4, Fgen, F h UT 2 [> A, 42 
A.\ : F\ in F\ 

A 2 : A in F 2 
F = F\ U F 2 

dom(A) n dom(A) = dom(r) 

B ^ dom(A) U dom(A) 

A = A U A U {B : V, leiCe : Ai ^ B^ tE2^E • 42 ^ B} 

A U A ensures amalgamability for F' 

4, Aen, F h LTi and UT 2 [> A, B 

A, Fgen, F h UT F',A 
B ^ dom(A) 

A' = A U {5 : A, a : 4 ^ 
ensures amalgamability for F" 

4, Aen, ^ ^ FT with (7 : F ^ F' F" ^ B 

4, Aen, A,4 

5 ^ dom(r') 

4, Aen, ^ ^ FT reduction a : F ^ F' F' U {B : F , a : B ^ 4}, B 

4, Aen, r h f/T [> A,5 

5 : V in r' 

4 ^ dom(r') U dom(Aen) 

4 U {4}, Aen, A U {4 : V, idE : A^ B}^UF' A', ^ 

L) ^ dom(r") 

4, Aen, ^ local A=UF within UF' [> A' [1^/4], ^[1^/4] 



It should be noted that, as a result of Casl lacking the amalgamation 
property, checking whether a subcontext ensures amalgamability of a context 
turns out to be undecidable; the same applies to the problem of checking 
whether an architectural specihcation has a denotation w.r.t. the extended 
static semantics. For these results, as well as for algorithms designed to cope 
with many typical cases, see [31]. 

We will make use of the following, purely syntactical, lemma: 



Lemma 5.1. Assume A ^ A, B is a finite set of unit names and 4, Aen, F h 
UT [> F'^Z. Then there exists B ^ B sueh that 4, Aen,^[^/4] h UF [> 
F'[B/A],Z[B/A]. □ 
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5.2 Soundness and Completeness 
of the Extended Static Semantics 

In this section we state and prove a soundness and completeness theorem 
for the extended static semantics, linking it to the more primitive static and 
model semantics. This serves both as an introduction to the soundness and 
completeness theorem for the proof calculus (see the next section) and as an 
addendum to the description of the extended static semantics in Sect. 111:5.6. 

5.2.1 Concepts 

In order to describe the relations between the extended static semantics and 
the model semantics we introduce a syntactic operation | • |, which removes 
everything except the signature from specifications. Thus, \ASP\ is the archi- 
tectural specification ASP with specifications used in declarations replaced by 
pure signatures. 

One might expect that an architectural specification ASP has a denotation 
w.r.t. the extended static semantics iff ASP has a denotation w.r.t. the static 
semantics and \ASP\ has a denotation w.r.t. the model semantics. Observe 
that the condition on the right side of the ‘iff’ seems to be the truly static 
concept that we are after, while the extended static semantics on the left side 
is merely our way of approximating that concept. 

That the implication from left to right holds (i.e, soundness) is fairly ob- 
vious. Unfortunately, the reverse implication is false (i.e., no completeness). 
This means that in some cases the extended static semantics will fail for stat- 
ically perfectly correct architectural specifications. There are two reasons for 
this and, as we will see, they show that those ‘statically perfectly correct’ spec- 
ifications are not actually that perfect - hence, the extended static semantics 
is in fact complete w.r.t. a slightly adjusted ‘truly static concept’. 

First, the model semantics is applicative^ that is, repetitive application 
of the same generic unit to the same argument must yield the same result. 
The extended static semantics does not keep track of which unit is applied 
where, and because of this there are examples of architectural specifications 
ASP such that ASP has no denotation w.r.t. the extended static semantics, 
although \ASP\ does have a denotation w.r.t. the model semantics (see [28]). 
To circumvent this problem, we introduce a modified, generative version of 
the model semantics, which we will denote by Note that using a gener- 
ative semantics is quite common, as exemplified by the generative functors 
of Standard ML, and that it serves a methodological purpose, making the 
design more transparent. The generative semantics may be defined either by 
allowing units to be multi-valued functions, or syntactically, by treating each 
declaration F : SP SP' such that F is applied n > 0 times in the given 
architectural specification as a list of declarations Fi,...,F^ : SP SP' ^ 
and then treating the ith. application of F as an application of Pi. We will 
be only interested whether an architectural specification has a denotation at 
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all w.r.t. the generative semantics and therefore it makes no difference for us 
which of the above approaches is taken. Note that if no generic unit in ASP 
is applied more than once then the generative and applicative semantics are 
equivalent. 

The reason for which even the equivalence ‘‘h ASP [> □ iff ASP has a 
denotation w.r.t. the static semantics and |t 4 /SP| has a denotation w.r.t. the 
generative model semantics” does not hold is that in Casl the consistency of 
a generic unit specification SP SP' does not guarantee that \SP SP'\ is 
consistent. The simplest example is when SP = { sorts 5, 5'; axioms Vx, y : 
s ' X = y; } and SP' = SP then { sorts s < s'; }. As a consequence, it may 
happen that ASP has no denotation w.r.t. the extended static semantics, while 
|A/SP| does have a denotation w.r.t. the model semantics for a trivial reason: 
ASP^s declarations were consistent, while \ASP\^s are not. 

To cope with this issue, we define a partial model semanties^ denoted using 
The idea here is that we make all generic unit signatures into eonsistent 
specifications, simply by supplying an additional possible value, namely T. 
However, before we dive into the details needed to state in full generality 
the soundness and completeness of extended static semantics (which we do in 
Theorem 5 . 4 ), we state the following simpler corollary of that theorem: 

Corollary 5.2. Let ASP be an arehiteetural speeifieation and assume that no 
generie unit in ASP is applied more than onee and no generie unit speeifiea- 
tion in \ASP\ is ineonsistent. Then ASP has a denotation w.r.t. the extended 
statie semanties if and only if ASP has a denotation w.r.t. the statie seman- 
ties and \ASP\ has a denotation w.r.t. the model semanties. □ 

We now introduce the machinery that is necessary in order to drop the 
special assumptions about generic units in the above result. Let Mod^(A) = 
Mod(A) U {T}, lSPj± = |5P] U {T}, Unit^(i:) = Mod^(A) and Unit^ 
(A ^ P') be the set of all partial functions F : Mod^(A) ^ Mod^(A') 
such that T G dom(F), T(T) = T, and for all M G dom(F), F{M) 7^ T 
implies F{M)\jj = M. Finally, for any generic unit specification SP SP' ^ 
by |/S!P ^ we denote the set of all F G Unit^(5Z5r[/SP] ^ sig[SP']) such 

that dom(F) = |/SP]^ and for all M G dom(F), F{M) G For any 

signature A by a P-P -model we will mean an element of Mod^(A). Further, 
ioT G : P ^ P' let : Mod^(A') ^ Mod^(A) denote the standard reduct 
•|cr which additionally takes T to T. 

Below we present those rules of the partial model semantics, which differ 
from the standard rules: 



^ A: SP ^ SP' F}\F e{SP ^ SP'j± } 
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Csyj{A^ siff[SP]} h tr o r 

Cs U {A szff[SP]}, {E\J{A^ M}\E (iC,M [SP] } h KT MEv 
for all P e C and M e |SP] if MEv{E U {A M}) ^ ± then 
MEv{E U {j4 M})\gig[sp] = M 

C^, Ch XA: SP»UT 

XE eC-XM e |SP]x ■ if M = 1 then 1 else MEv{E U {yf M}) 

Cs,ChUT MEv 
for all E eC, MEv{E)\^ e dom(P(A)) 

Cs{A) = Sf^ Sr 

T : Sa ^ A and a' : Sr ^ A form the selected pushout for (cr, LSf cSr) 
for all P e C, if EiA){MEv{E)\^) ^ 1, then 
there exists a unique Zi-model Me such 
that Me\t = MEv{E) and = E{A){MEv{E)\^) 

Cs, Ch A[UT &t a : Sf ^ Ea]^± 

XE ec ■ if E{A){MEv{E)\^) = ± then ± else Me 



C,hUTi> Si 

C,^UT2> S2 
S = Si U S 2 
Cs,C\-UTi^e MEvi 
Cs,C\-UT2^± MEv2 

for all P e C, if MEvi{E) ^ S and MEv 2 {E) ^ ±, 
then there exists a unique P-model Mp such 
that Me\ex = MEvi{E) and Me\e 2 = MEv 2 {E) 

Cs, ChUTi and UT 2 

XE G C • if MEvi{E) = ± or MEv 2 (E) = ± then ± else Me 
C s,ChUT MEv 

for all P G C there exists a unique A-P'-niodel Mp with Mx;|^ = MEv{E) 

Cs,ChUT with a : S ^ S' XE eC ■ Me 
C s,ChUT MEv 

Cs,ChUT reduction a : S ^ S' XE e C ■ MEv{E)\^ 

Cs^ur> S 
C„ChUT MEv 

C* S},{E\J{A ^ MEv{E)}\E G C, MEv{E) ^ ±} ^ UT' ^eMEv' 

Cs, C \- local A = UT within UT' =>x 

XE eC ■ if MEv{E) = 1 then 1 else MEv'{E U {yf MEv{E)}) 
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We will combine the partial and generative versions of the model semantics, 
creating a partial generative semantics, denoted by The following is an 
important property of the partial model semantics: 

Proposition 5.3. Suppose that ASP has a denotation w.r.t. the statie seman- 
ties. If ASP has a denotation w.r.t. the partial (generative) model semanties, 
then it also has one w.r.t. the standard (generative) model semanties. If no 
generie unit deelaration in ASP is ineonsistent, then the reverse implieation 
also holds. □ 

We may now state our main soundness and completeness theorem for the 
extended static semantics: 

Theorem 5.4. For any arehiteetural speeifieation ASP we have h ASP [> □ 
if and only if ASP has a denotation w.r.t. the statie semanties and \ ASP\ has 
a denotation w.r.t. the partial generative model semanties. 

Clearly, the following theorem is then a corollary: 

Theorem 5.5. For any arehiteetural speeifieation ASP in whieh no generie 
unit speeifieation is applied more than onee we have h ASP [> □ i/ and only if 
ASP has a denotation w.r.t. the statie semanties and \ASP\ has a denotation 
w.r.t. the partial model semanties. 

In fact, using the syntactic definition of the generative model semantics 
one easily sees that Theorem 5.5 implies Theorem 5.4. Therefore we will only 
prove Theorem 5.5. Please note that this proof will be institution- independent. 

5.2.2 Proof 

In order to prove Theorem 5.5 (and thereby Theorem 5.4 as well), we will 
now need some auxiliary notions. A T-unit family F = {Fu}u edom(rgen) 
P-eonsistent with a generic context Pgen A A : P ^ P' in Pgen implies 
Fa ^ \P ^ P'\^ (i-e.. Fa C Unit^(A ^ P') and additionally dom(TA) = 
Mod^(A)). 

If .4 C dom(T) \ dom(T^en) then by Cs^A^PgenihS) we denote the static 
context which takes any unit name in dom(T^en) to the appropriate generic 
unit signature defined in Pgen and any unit name in A to the appropriate 
signature defined in P. 

Let Pgen be a generic context and UP a unit term. By V(UT) we will denote 
the set of generic unit names from dom(T^en) used in UT^ and by P{UT) the 
set of generic unit names from dom(T^en) not used in UT; these sets depend 
on Pgen as well, but Pgen being fixed this should not cause confusion. 

Lemma 5.6. Assume that A C dom(T) \ dom(T^en) ci'^d that no generie unit 
is applied more than onee in UP. Define Cg = Cs{A^ Pgem ci'^d suppose 
that C fits Cg and that there exists a surjeetive funetion 0 from C onto the 
set of all model families eonsistent with P , and sueh that: 
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3.) for any E eC, 9{E)\j^ = E\j^; _ 

h) if El and E 2 coincide on AU V{UT), then 0{Ei) = ^(£” 2 ) (in the strong 
sense, i.e., either both are undefined, or both are defined and equal). 

Then A,Egen,r h UT \> Ei,Z for some Ei and Z if and only if Cg 
UT \> E for some E and Cg, C \~ UT MEv for some MEv. 

Moreover, if both sides of the equivalence hold, then: 

1. Z : E in Ei; 

2. there exists a surjective partial function 0i from C onto the set of all model 
families consistent with Ei, and such that: 

a) for any E e C, if Oi{E) is defined, then ^i(^)|dom(r) = 9{E); 

b) if Ei,E 2 C C coincide onV{UT) and ifO{Ei) = ^(^ 2 ); then Oi{Ei) = 
^ 1 (^ 2 ) (in the strong sense); 

c) MEv = XE G (C • if E e dom(^i) then Oi{E)z else A. 

Proof. The proof is by induction over the structure of UT. 

The idea is that 0 defines the way in which any environment E ^ C is 
represented by a model family consistent with E. We assume that all families 
consistent with E are used as representations, that they really are represen- 
tations (condition a), and that they do not depend on generic units used in 
UT (condition b), which is possible, since no generic unit may be used both 
inside and outside UT at the same time. 

Then the function 0i is a kind of extension of 0. It is undefined in those 
cases where the result model is T. Point (2b) again states that the result may 
only depend on generic units actually used in UT. 

The first case is UT = A. Assume the left side of the equivalence holds. 
Then Ei = E, Z = A and A ^ A. Thus Cg h UT \> Cg{A) and trivially 
Cg, C ^ UT XE G C • E{A). As for the ‘moreover’ part, (1) is obvious. We 
then take 0i = 0. Clearly, for T” G (C we have MEv{E) = E{A) = E{Z) = 
0{E)z = Oi{E)z^ which proves point (2). 

So, assume now that the right side holds. Then Cg{A) = E, which implies 
Ae A, and so A, Egen.E h bT [> T, A. 

The second case is UT = A [ UT' Hi a : Ef ^ Ea ]. 

Assume the left side holds. Thus, by the extended static semantics rule for 
unit application, we have: 

LA A : E f ^ Er in Egen for some E^', 

LB A, Egen^E ^ UT' Ea^Aa for some Ea and 
I.C Aa : Ea in 

I.D there exists a selected pushout r : Ea ^ A, a' : Er ^ A for {a, 

I.E Z ^ dom(iA) and there exist Af,Ar ^ dom(iA), all distinct, such that 
for E' = Ea U {Aj : Ef, c : Af — > Aa, Arp : Ep, iEfdEr • Af — ^ Apj and 
El = E' U {Z : A, T : Aa ^ Z, a' : Ap ^ Z} we have that E' ensures 
amalgamability for Ei. 

Using (LB) and the induction hypothesis we infer that there exist E and 
MEv a such that: 
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ILA Cs^UT' \> 

ILB Cs.C^UT' MEva] 

II. C Aa : E in Fa and so by (I.C) we have E = Fa] 

ILD there exists a surjective partial function Oa from C onto the set of all 
model families consistent with and such that: 

1. for any E” G (C, if Oa{E) is defined, then ^a(A')|dom(r) = ^{E); 

2. if Ei^E 2 G C coincide on V{UT) \ {A} and if 0{Ei) = ^(E' 2 ), then 
Oa{Ei) = 0 a{E 2 ) (in the strong sense); 

3. MEva = XE G (C • if E” G dom(^a) then Oa{E)A^ else 

Because, by (LA), Cs{A) = Ef ^ Er^ E = (ILA) and (LD) we may 
conclude that Cg ^ UT \> A. 

To prove Cg^ C \~ UT MEv for some MEv we need only take any 
E e C with E{A){MEva{E)\-^) ^ T and show that there exists a unique 
Z\-model Me such that Me\t = MEva{E) and Me\(t' = E{A){MEva{E)\cr). 
Since MEva{E) ^ T, the model family N = Oa{E) is defined and consistent 
with Ea and Na^ = MEva{E). Defining additionally NAf = MEva{E)\cr and 
Na^ = E{A){MEva{E)\cr) 7 ^ T we see that we have a model family consistent 
with EX By (LE) it uniquely extends to a family Q consistent with Ti, which 
ends the proof from left to right, since as Me we may take Qz- 

As for the ‘moreover’ part, (LE) implies (1). For any E ^ C we then define 
the Oi{E) of (2) as follows. If E{A){MEva{E)\^) = T, then we let Oi{E) be 
undefined; otherwise Oi{E) is defined to be Oa{E) extended by Oi{E)Af = 
Oa{E)\(j^ Oi{E)a^ = Me\(t' and Oi{E)z = Me- Clearly, if defined, Oi{E) is 
consistent with Ei. Also, 0i is onto, for let Q be any model family consistent 
with El. Then Q|dom(ra) is consistent with iA, and so, by (ILD), there exists 
E G dom(^a) such that Oa{E) = Q|dom(ra)- We may now define E' to be E 
changed so that E'{A) is a unit taking Qa/ to and everything else to T. 
We then have Oi{E') = Q, since by definition ^i(T'')|dom(ro = Qldom(r') and 
E' ensures amalgamability for Ei. Finally: 

1. for E eC.if Oi{E) is defined, then 6>i(^)|dom(r) = ^a(^)|dom(r) = 0{E) 
(the second equality by virtue of point 1 of (ILD)); 

2. A Ei^ E 2 G (C coincide on V(UE) 3 A and if 0(Ei) = ^(£” 2 ), then by point 
2 of (ILD) we have ^a(Ei) = 0a{E2)^ and so Oi{Ei) = 0i{E2)] 

3. for E” G (C, if E{A){MEva{E)\-^) = T then 9i{E) is undefined and 
MEv{E) = T; otherwise Oi{E) = Me = MEv{E). 

Finally, we prove the implication from right to left. 

Assume that Cg \~ UT \> E and Cg, C \~ UT MEv. From the static 
and partial model semantics rule for unit application we know that: 

LA Cg{A) = Ef ^ Er foT some 
LB CghUT^ > Ea; 

I.C there is a selected pushout r : Ea ^ E ^ a' : Er ^ E for (a, tEfCU^); 

LD Cg^ C \- UT' MEva for some MEva] 
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LE for all E G (C, if E{A){MEva{E)\^) ^ A, then there exists a unique E- 
model Me such that Me\t = MEva{E) and M^|cr' = E (A) (MEva{E)\cr) . 

By (LB) and (LD) and the induction hypothesis we may infer that: 

II. A Egem E h UT' [> Ea^Aa for some Ea and 

ILB Aa : Ea in 

II. C there exists a surjective partial function Oa from C onto the set of all 
model families consistent with Ea^ and such that: 

1. for any E G (C, if Oa{E) is defined, then ^a(^)|dom(r) = 

2. if Ei^E 2 G C coincide on V{UT) \ {A} and if 0{Ei) = ^(^ 2 ), then 
Oa{Ei) = 0 a{E 2 ) (in the strong sense); 

3. MEva = XE G (C • if E G dom(^a) then Oa{E)A^ else A. 

Take arbitrary distinct Af^A^^Z ^ dom(Aa) and let A' = Aa U {Aj : Aj, a : 
Af — > Aa, Aj> : iEfdEr • ^/ — ^ ^r} cind E\ = A^ U {A : A, t : Aa — ^ 

A, a' : Ar ^ A}. Because we have (LA), (II. A), (ILB) and (LC) all we 
need in order to prove A, A^en,L^ ^ LA [> Ai,A is show that E' ensures 
amalgamability for Ai. 

So, take any model family Q consistent with A'. Since, by (ILC), Oa is onto, 
there must exist Ea ^ C such that Oa{Ea) = Q|dom(ra)- Let E be Ea changed 
so that A (A) is a unit taking Qa/ to and everything else to A. Observe 
that by condition b and point 2 of (ILC) MEva{E) = MEva{Ea) = Qa«5 
also, E{A){MEvama) = E{A){QaE) = E{A){Qa,) = Qa^, so, by (LE), 
there exists a unique A-model Me such that Me\t = MEva{E) = Qa^ 
and M^lcr' = E{A){MEva{E)\cr) = Qa^- This is equivalent to saying that 
Q U {A ^ Me} is the unique model family consistent with Ai and extending 
Q. 

The cases of and, with and reduction are fairly easy and we omit them. 
The final case is UT = local A = UT' within UT" . 

Assume the left side holds. Thus, by the extended static semantics rule for 
local unit definition, we have: 

LA A, A^en, A h UT' [> A', A for some T' and A; 

LB A : Ab in A' for some A^; 

LC A ^ dom(A') U dom(A^en); 

LD for A* = A U {A} and A^ = A' U {A ^ A^, id^;^ : A ^ A } we have 
A*, A^en, A^ h UT" [> T" ^E for some E" and A; 

LE D ^ dom(A"); 

LE Ai = A" [A /A] and A = A[A/A]. 

Using (LA) and the induction hypothesis, we infer that: 

II. A Cs^UT' > E' for some A'; 

ILB Cs.C^UT' MEv' for some MAv'; 

ILC A : A' in E' and so, by (LB), Eb = A'; 

II. D there exists a surjective partial function 0' from C onto the set of all 
model families consistent with A', and such that: 
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1. for any E” G (C, if 0'{E) is defined, then ^'(^)|dom(r) = 

2. if ^ 1 , ^2 C C coincide on V{UT') and if 0{Ei) = 6 >(^ 2 ), then e\Ei) = 
O' {E 2 ) (in the strong sense); 

3. MEv' = XE G (C • if E” G dom(^') then 0\E)b else ±. 

Observe that C dom(r^) \ dom(i~^en) (by (I-C)) and that no generic 
unit name in UT" is applied more than once. Let (C* = (C 5 (.4.,< , i~^en , , C* be 

the context consisting of environments of the form EVJ{A ^ MEv\E)}^ where 
E ^ C and MEv'{E) ^ ±, and define 0*{E*) = |dom(£;*)\{A}) O {A 

E*{A)} for E* G C*. 

Then 0* is a function from (C* onto the set of model families consis- 
tent with T*. First, clearly ^*(T'*)|dom(r') is consistent with E\ and more- 
over 0*{E*)a = E*{A) = MEv'{e*\^q^(^e*)\{A}) = 0'{E*\^q^(^e*)\a)b = 
0*{E*)b- Second, 0* is onto, for take any model family Q consistent with 
There exists an environment E ^ C with 0'{E) = Q|dom(r')- Then setting 
E* = EU{A^ MEv'{E)} we have E* G C* and (9*(^*) = Q. 

Also, 0* satisfies conditions a and b: 

a) if T”* G (C*, then ^*(T'*)|^^ = since the equalities ^*(T'*)|^ = 

0'{E*\dom(E*)\{A})\A = E*\a Md and since 0%E*)a = ^*(A); 

b) if El and E^ coincide on A:^AV{UT") then ^*(T'f) = |dom(£;*)\{A}) ^ 

{A ^ El{A)} = ^'(^ 2 *ldom(^*)\{A}) U {A ^ ^I(A)} = r (^1). 

By (I.D) and the induction hypothesis we may now infer that: 

III. A Cl h UT" \> E" for some A"; 

III.B Cl, C* h UT" MEv" for some MEv"; 

III.C E : E" in T"; 

III.D there exists a surjective partial function 9" from (C* onto the set of all 
model families consistent with T" , and such that: 

1. for any E^ G C\ if 0" {E^) is defined, then <9"(^*)|dom(rc = ^*(^*); 

2. if El, El G C* coincide on V{UT") and if 0*{EI) = 0*{EI), then 
0"{EI) = 9" {El) (in the strong sense); 

3. MEv" = XE* G C* • if G dom((9") then 9"{E*)e else T. 

From (I.C), (II. A) and (UFA) we conclude that Cg k UT \> E" . From 
(II. B) and (III.B) we conclude that Cg, C \~ UT MEv, where dom(MEv) = 
C and for any E ^ C , li MEv'{E) = T, then MEv{E) = T and otherwise 
MEv{E) = MEv"{E U {A ^ MEv'{E)}). This ends the proof from left to 
right. 

As for the ‘moreover’ part, Z = E[D/A] : E" in T"[D/A], because of 
(III.C); this proves point (1). Now, for any E e C let 9i{E) be undefined if 
MEv'{E) = T, and otherwise be the model family 9"{E U {A ^ MEv' {E)}) 
with the node A relabeled to D. Clearly, if 9i {E) is defined, then it is consistent 
with El. Also, 9i is onto the set of all model families consistent with Ti. To see 
this, take any model family Q consistent with Ti. Let Rhe Q with the node 
A relabeled to D. Of course R is a model family consistent with T" . Thus, 
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there exists, by (IILD), an environment E* G C* such that 9*{E*) = R. Let 
E = ^*|dom(£;c\{A}- We now have 0" {E U {A ^ MEv'{E)}) = 0"{E*) = R. 
Hence, Oi{E) equals R with the node A relabeled to 14, which in turn equals 
Q. Further: 

1. for any E e C, if 9i(E) is defined, then ^i(F)|dom(r) = ^(E) because of 
point 1 of (IILD) and (ILD); 

2. if Ei^E 2 G C coincide on V and if 0{Ei) = ^(^ 2 ), then Oi{Ei) = 0i{E2) 
(in the strong sense) because of point 2 of (IILD) and (ILD); 

3. MEv = XE G (C • if F G dom(^i) then Oi{E)e else A because of point 3 
of (IILD) and (ILD). 

Now we prove the implication from right to left. 

Assume that Cg \~ UT \> E and Cg^ C \~ UT MEv. Thus, by the static 
and partial model semantics rule for local unit definition, we have: 

LA A ^ dom{Cg); 

LB CghUT' > E' for some A'; 

I.C CgU{A^ E'} h UT" \> E- 

I.D Cg.ChUT^ MEv' for some MEv'-, 

I.E CgU {A ^ E'}, {E U {A ^ MEv'{E)}\E G C, MEv'{E) 7 ^ A } h 
UT" MEv"; 

I. F dom{MEv) = C and for all F G C, if MEv'{E) = A then MEv{E) = A 

and otherwise MEv{E) = MEv"{E U {A \-^ MEv' (E)}). 

From (LB) and (LD) and the induction hypothesis we infer that: 

II. A A^Egen^r h UT' [> T'^B for some T' and B - since A ^ A (by (LA)), 

we may assume, by Lemma 5.1, that A ^ dom(A'); 

II.B B :E' in T'; 

II. C there exists a surjective partial function 9' from C onto the set of all 
model families consistent with A', and such that: 

1. for any A G (C, if 9' {E) is defined, then ^^(A)|dom(r) = ^{E); 

2. if Ai, A 2 G C coincide on V{UT') and if (9(Ai) = 6 >(A 2 ), then (9'(Ai) = 
9'{E2) (in the strong sense); 

3. MEv' = XE G A • if A G dom(^') then 9'{E)b else A. 

Let A^ = A' U {A : A', id^;/ : A B} and A* = A U {A}. Observe 
that A* C dom(A^) \ dom(A^en), by (LA), and that no generic unit name in 
UT" is applied more than once. Let A* = As(A*, A^en, A^) and A* be the 
context consisting of environments of the form A* = A U {A ^ MAv'(A)}, 
where A G A and MEv' {E) ^ A, and let 9*{E*) = ^'(A*|dom(£;*)\{A}) 

A* G A*. Then 9* is a surjective function from A* onto the set of all model 
families consistent with A', and such that: 

a) for any A* G A*, ^*(A*) extends the model family {E*{U)}ueA^i 

b) if Af and A| coincide on A* U V{UT")^ then ^*(Af) = ^*(A|) (in the 
strong sense). 
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Thus, by (TC), (I.E) and the induction hypothesis we may infer that 
^ UT " [> F"^E for some F" and E. From this together with 
(IT A), (II.B), (LA) we may conclude that for some D ^ dom(T") we have 
A^Fgen^F h UT [> F^^[D/A]^E[D/A]^ which completes the proof. □ 

Proof (Theorem 5.5). Assume ASP = units UDi . . .UDn result UT (the 
generic case is similar and we omit it) and that no generic unit in ASP is 
applied more than once. 

It should be clear that all we need to prove is that if Fgen and F have 
disjoint domains, A = dom(T), Cg = Cs{A, Fg^^^ F) and C contains all envi- 
ronments E = FUM, where F is a T-unit family consistent with F^en and M 
is a model family consistent with F, then A^ Fg^^^ F h UT [> Fi, Z for some 
Fi and Z if and only if Cg \~ UT \> E for some E and Cg^ C \~ UT MEv for 
some MEv. We may use Lemma 5.6, since A C dom(F)\dom(F^en )7 no generic 
unit name in UT is applied more than once, and the function 6{E U M) = M 
satisfies conditions a and b. This completes the proof. □ 



5.3 The Proof Calculus 

While specifications SP which appear in architectural specifications need not 
form an institution themselves, they are assumed to be built over some insti- 
tution /; in the case of Casl, this is the institution of Casl logic. Because 
the institution I might not have weak amalgamation, we are forced to transfer 
part of the verification process to a specification formalism built over an insti- 
tution J which has this property. Possible choices of J and of the specification 
formalism over J are discussed below. 

We use the notation^ SP for finite sets of specifications over a common 
signature E. If M is a F-model, then M SP means that M SP for all 
SP G SP. If SP is a F-specification, then SP^ ^SP means that for any E- 
model M, if M \=^ SP then M \=^ SP. The relation ^ is the proof-theoretic 
counterpart of . It is sound w.r.t. the relation ^ if ^ C ^ ^ and it is 
complete if ^ ^ 

Our aim is to create a calculus in which, using an institution J with a 

relation sound w.r.t. the relation , one could derive statements of the 
form h ASP :: USP so that the following theorem holds: 

Theorem 5.7. Suppose that h ASP [> □ and that no generie unit deelaration 
in ASP is ineonsistent. If is eomplete w.r.t. the relation ^ , then 

h ASP :: USP 



if and only if 

Many concepts extensively used in this section have been defined in Chap. 4. 



2 




348 IV:5 Architectural Specification Calculus 



h ASP UEv 

for some UEv such that for all E G dom.(UEv) , 

UEv{E) G {USPj. 

The reason for assuming that no generic unit declaration is inconsistent 
should be clear: without it the problem is not recursively enumerable, since 
the problem of proving consistency is not recursively enumerable. 

It is possible to have a calculus where the assumption on ASP having a 
denotation with respect to the extended static semantics can be dropped. It 
is at the same time possible to have a calculus such that the standard (ap- 
plicative) model semantics can be used in the above theorem. Unfortunately, 
such calculi are quite complex - we refer the interested reader to [28] and [29] . 



5.3.1 Definition of the Proof Calculus 

We assume that both in the specification formalism over /, as well as in that 
over J, for any signature morphism a : E ^ A and U-specification SP^ there 
exists a translation of SP along a, denoted a{SP)^ i.e., a Z\-specification such 
that for any Z\-model M we have M G |cr(/SP)] if and only if M|cr G {SPj. 
We also assume the existence of basic specifications, that is, for any finite 
set of U-sentences there exists a U-specification SP such that {SPj is the 
class of models satisfying all the sentences from that set. For Casl structured 
specifications the translations required can be obtained by combining with 
and and constructs, the latter being needed if a is not surjective enough, and 
finite sets of sentences are captured by Casl basic specifications - this relies 
on the fact that surjective signature morphisms, signature extensions and the 
sentences involved are expressible in the Casl syntax. 

The contexts introduced below differ from those used in the extended 
static semantics only by additional specification components. Therefore we 
will freely apply concepts defined previously for ‘bare’ contexts to those de- 
fined below. 

A generic context Pgen is a finite set of declarations A SP SP\ 

where U ^ U' is the signature of the generic unit specification SP SP'. 

A context T is a finite set of declarations of two forms: 

• A SP^ where SP is a finite set of specifications over U; 

• a : A ^ where A izia SP a and B :zb SPb in P and a : Ea Eb is a 
signature morphism. 

A given unit name A may be declared at most once in a context P ; again, 
the same applies to unit names in generic contexts Pgen- We say that A : E 
in P to express the fact that A :z SP in P for some SP. Analogously we use 
the phrase A : E ^ E' m Pgen- If A and A are two contexts and for all 
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A e dom(Ti) n dom(/ 2 ) we have A : U vcv Fi \i and only if A : in then 

their sum Fi U l 2 is a context as well. 

Any context F can be treated as a diagram in the signature category, 
whose nodes are additionally labeled by sets of specifications (though the 
signature morphisms in F need not be specification morphisms). We will say 
that A, {r]u}uedom(r) is a weakly amalgamahle cocone over T, if it is a weakly 
amalgamable cocone over the above-mentioned ‘bare’ diagram without the 
labeling^ . 

Recall from Chap. 4, Remark 4.3, that by R = we denote a 

model-isomorphic simple theoroidal comorphism from the institution I of our 
interest to some institution J which admits weak amalgamation. We assume 
that for any A-specification SP in /, there exists a /S'z^(^(A))-specification 
R{SP) in J such that for any model M' \=^ Ax{^{F)) we have: 

M' R{SP) ^ (3{M') SP 

In the presence of basic specifications this is equivalent to assuming that the 
comorphism R may be extended to a comorphism from an institution of spec- 
ifications over I to an institution of specifications over J; hence, we call it 
the comorphism condition. Please note that specifications over I may be very 
different from specifications over J, e.g., the former could be flat specifications 
and the latter structured specifications. For a more practical example cf. the 
discussion below concerning the application of these ideas to Casl structured 
specifications and Casl logic. For any finite set of A-specifications SP by 
R{SP) we denote the set of specifications R{SP) augmented by a basic speci- 
fication containing the axioms Ax{^{F)). For any context F in /, by R{F) we 
denote the context in J obtained by mapping any declaration A SP in F 
to A :sig(^(u)) R{SP)^ and any declaration a : A ^ B in F to ^{cr) : A ^ B 
(where ^{cr) is treated as a morphism in the signature category of J). 

The problem of developing a proof calculus for architectural specifications 
is parametrized by the institution I and by a formalism of specifications over 
F In order to solve this problem as announced in Theorem 5.7 additional 
parameters are needed: an institution J with weak amalgamation, a specifi- 
cation formalism over J with a relation sound w.r.t. ^ , and a simple 
theoroidal model-isomorphic comorphism R : I ^ J such that for any spec- 
ification SP over I a specification R{SP) over J satisfying the comorphism 
condition may be defined. Moreover, the specification formalisms must both 
have translations and basic specifications must exist in them. 

If we apply the proof calculus to Casl, then the institution I is simply 
the institution of Casl logic, and the specification formalism over I is the 
formalism of Casl structured specifications^. Of course, the other parameters 

^ For a definition of weakly amalgamable cocone over a diagram see Chap. 4. 

^ Note however that, as announced in the introduction to this chapter, we disregard 
here the global environment and treat specifications as self-contained entities. 




350 IV:5 Architectural Specification Calculus 



may be chosen in many ways; we will now describe one possible choice which 
makes use of the tools developed in the previous chapter. 

As the comorphism R : I ^ J one may take either the embedding of 
(subsorted) Casl in many-sorted Casl, or its embedding in so-called En- 
riched Casl - for a discussion of these possibilities see Chap. 4, Remark 4.3. 
Specifications over J will be pairs SP = {N^VQ)^ where VQ is a development 
graph over J and N a node in that graph. Then we define sig[SP] = 
and {SP} = M.odj)g{N). For any Casl specification SP over I (i.e., over the 
Casl logic), the specification R{SP) over J may be obtained as follows: first, 
SP is translated to a pair consisting of a development graph VQ over I and a 
node N in that graph, as described in Sect. 4.7; next, this development graph 
is translated via the comorphism R to a development graph R(VQ) over the 
institution J, as described in Sect. 4.3; then, the specification R{SP) over J 
is simply the pair (A^, R(VQ)). 

Finally, the relation [Ni^VQi) {N2,P02) holds if and only if VQi U 

VQ 2 A ^2 (we assume here that VQi and VQ 2 are disjoint). 

The disjointness assumption made above shows that the proposed transla- 
tion would actually be quite ineffective in the presence of a global environment, 
losing much of the sharing information that could be kept in development 
graphs. Fortunately, in the proof calculus the non-signature part of specifi- 
cations of the form R{SP) is used only in proof obligations, which have the 
general form: 

IJ 

In Remark 4.26 it has been shown how such proof obligations may be dis- 
charged while keeping the structure of specifications. When using these meth- 
ods it is actually not necessary to define R{SP) explicitly. 

We now present the rules of a proof calculus which meets the requirements 
stated in Theorem 5.7. 



h ASP :: USP 



u • ■ • u u • ■ • u r" h ue ■■ usp 



h units UDi . . . UDn result UE :: USP 
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h UD :: rge„,r 



h^:SP::0,{^:,,g[SP] {SP}} 



^A:SP^SP' :: SP ^ SP'}, 0 



Pgen,r^UE ::USP 

The sets dom(r^en) and dom(r') should be disjoint. 

rge„,P^Ur::P',A 

for all U G dom(r''), we have U :su SPjj in P' 

[m] t/Gdom(r') is a weakly amalgamable cocone over R{r') 

71a{R{SP)) Up6dom(P') Vu(R{SPu)) 

rge„,r h CZTquaLT; :: SP 

sig[SP] = sig[SPi] = E 

RiSPi)'^igi^i^y)Ri{SP}) 

Rgen 5 ru{A:s {SP}}^UT::P',B 
B : sig[SP 2 ] in P' 

for all U G dom(r''), we have U :su SPjj in P' 

V {Vu} t/Gdom(r') is a weakly amalgamable cocone over R{r') 

Vb{R{SP 2 )) Up6dom(P') Vu{R{SPu)) 

Pgen, P'r XA-. SP»UP :: SPi^ SP 2 



Pgen,P^UP::P',A 



The context T is a subcontext of Tb 
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rgen.r h A :: r, A 

A SPf SPr in Pg^n 

Pgen.P ^ W II Pa, Aa 

for all U G dom(iA), we have U i^u in Pa 
{Vu}uedom(ra) is cl weakly amalgamable cocone over R{Pa) 

rjAARi^^iSPf))) Uc/edom(A) Vu{R{SPu)) 

T : Pa ^ A and a' : Pr ^ A form the selected pnshont for (a, 

Aj, Ar, B ^ dom(ra) 

Pgen , P ^ A[UT G : Pf ^ Pa]'d Pa^ {Af :Uf {SPf}, a : Af ^ A^, 

Ar -Ur- ^EfCEr- • Af A^, 5 0, T : Aa ^ B ^ a' : A^ ^ B}, B 

Pgen,P ^ UTi II A, Ai 
Pgen,P ^ II A, ^2 

I Xj^ in 

A 2 : X 2 in I 2 

dom(r'i) n dom(r 2 ) = dom(r) 

B ^ dom(Ci) U dom(/ 2 ) 

Bgen, BhUTi and UT 2 :: A U CaU 
{B :siUS2 0 > t^Ei<zSiUS2 '■ Ai ^ B, ls2<zEiUE2 • ^2 ^ B),B 

Aen,rhCT::r',A 
B ^ dom(r') 

Ae„, r h UT with (7 : r ^ V :: A U {B 0, (7 : A ^ B}, B 

rge„,r^ur----r',A 
B i dom(r') 

Pgen, P h UT reduction a : S ^ E' T' iJ {B is 9,cr : B ^ A}, B 

Pgen,P^UPy-P',B 
B: E in r' 

A ^ dom(r') 

Pgen, P^{A:s 0, ids : A ^B}U UP' :: T", E 
D i dom(r") 

Pgen,P 'f- local A = UT within UT' :: T"[D IA],E[D /A] 

The following lemma is analogous to Lemma 5.1: 

Lemma 5.8. Assume A ^ A, B is a finite set of unit names, Cs{A, \Pgen Ur|) 
h UT O E and Tgen,P h UP :: T',Z. Then there exists B ^ B such that 
Pgen,P[B/A]^UT::r'[B/A],Z[B/A]. □ 
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5.3.2 Soundness and Completeness 

Theorem 5.7 is a corollary of the following theorem: 

Theorem 5.9. Suppose that h ASP [> □; that no generic unit declaration 
in ASP is inconsistent and that no generic unit in ASP is applied more than 
once. If^'^ is complete w.r.t. the relation ^ ; then h ASP :: USP if and only 
if h ASP => UEv for some UEv such that for all E G dom(UEv) , UEv{E) G 
pSP]. 

Before we provide a proof of Theorem 5.9, we would like to comment on the 
above calculus. It is clear that it is really an algorithm presented in the form 
of a calculus. This algorithm generates proof obligations of the form SP 
SP^ and all non-trivial decisions concerning proof- search have to be taken in 
the process of discharging those obligations. A calculus for discharging proof 
obligations of this form is described in the previous chapters, where they are 
translated into theorem links in development graphs (see Definition 4.22). A 
solution for the specific case of proof obligations generated by the architectural 
specification proof calculus is provided in Remark 4.26. 

What remains to be done now is to prove Theorem 5.7. 

For any generic context Pgen and context T, by \Pgen\ and |T| we denote 
these contexts after removing all specifications and leaving the signatures only 
(i.e., we obtain contexts in the sense of Sect. 5.1). 

Let T be a context. A model family M consistent with |T| is consistent 
with P if Ma \=u SP for A SP in P. Similarly, let Pgen be a generic 

context. A unit family E consistent with \Pgen\ is consistent with Pgen if for 
any U SP SP' in Pgen we have Eu G {SP SP'j. 

The following lemma explains the meaning of the proof obligations ‘gen- 
erated’ by the above calculus: 

Lemma 5.10. Let P be a context with U :eu SPu for all U G dom(T). 
Also, let A G dom(T) and SP be a E a~ specification. Finally, assume that 
the sink E, {Tu}uedom(r) is a weakly amalgamable cocone over R{P)> Then 

the refinement r]A{R{SP))^ ^ Ut/Gdom(r) hu{R(SPu)) holds iff for any model 
family M consistent with P we have Ma \=Ea 

Proof. Notice that f3 defines a bijection between model families consistent 
with P and model families consistent with R{P). Moreover, this bijection 
preserves and reflects the satisfaction of specifications. Thus the right side is 
equivalent to saying that for any model family N consistent with R{P) we 
have Na \=sig(^(UA)) This statement is equivalent to the left side, 

since E, {riu}uedom(r) is a weakly amalgamable cocone over R{P). □ 

If E fits Cg-, then define E± to be the environment taking any U G 
dom((75) with Cg{U) = E E' to the T-unit AM G Mod^(A) • if M G 
dom{E{U)) then E(U){M) else T, and any U G dom(C 5 ) with Cs(U) = E to 
Ep). 
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Lemma 5.11. Assume that A C dom(i^)\dom(i~^en) ci'^d that no generic unit 
is applied more than once in UT . Define Cg = Cg{A^ l^^enl, |^|) ci'^d suppose 
that C fits Cg, that {^(^)}t/Gdom(rger.) ^ unit family consistent with Dg^n 

for all E ^ C , and that there exists a surjective function 0 from C onto the 
set of all model families consistent with E, and such that: 

a) for any E eC, 0{E)\j^ = E\j^; _ 

h) if El and E 2 coincide on AA V(UT), then 0{Ei) = ^(£” 2 ) (in the strong 

sense). 

Assume also that we have a context \C\ which fits Cg and such that E ^ C 
implies E± ^\C\, that Cg h UT \> E, and that Cg, \C\ h UT MEvj_. 

If is complete w.r.t. the relation ^ ; then Tge^^E h UT :: Ti,Z for 
some Ti and Z if and only if Cg, C \~ UT ^ MEv for some MEv. 

Moreover, if both sides of the equivalence hold, then: 

1. Z : E in Ei; 

2. there exists a surjective total function 0i from C onto the set of all model 

families consistent with Ei, and such that: 

a) for any E eC, Oi{E)\dom(r) = 0{E); 

b) if Ei,E 2 C C coincide on V{UT) and if 0{Ei) = ^(^ 2 ); then Oi{Ei) = 
^ 1 (^ 2 ); 

c) MEv = XE eC • Oi{E)z = XE e C • MEv±{E±). 

□ 

The proof of the above lemma is long and very similar to that of Lemma 5.6 
and therefore we omit it. In the proof, Lemmas 5.8 and 5.10 are used. 

Proof (Theorem 5.9). Assume that ASP has a denotation w.r.t. the extended 
static semantics, that no generic unit specification in it is inconsistent, and 
that no such unit is applied more than once. We will prove the theorem for 
the case ASP = units UD\ • • • UD^ result UT, the generic case being very 
similar. 

Suppose h UDi :: E^^„, C* for 1 < i < n, and let Egen = U ■ ■ ■ U 
E = r'- U • • ■ U -T", A = dom(r) and E be the set of generic unit names from 
dom(T^en) used in UT. Also, let Cg = Cg{A, |T^en|, |^|) and let \C\ contain 
all environments of the form F U M, where F is a T-unit family T-consistent 
with |F^en| und M is a model family consistent with |F|. By Theorem 5.5 we 
then have Cg h UT \> E for some E and Cg, \C\ h UT MEvj_ for some 
MEvj_. Now let C contain all environments of the form F U M, where F is a 
unit family consistent with F^en und M is a model family consistent with F, 
and define 0{F U M) = M. Clearly, E ^ C implies E± c \C\, 0 is onto the set 
of all model families consistent with F, 0{F U M) extends M and does not 
depend on unit names not in A. 

By Lemma 5.11 we have that Ege^, E h UT :: T' , A for some F' and A iff 
Cg, C \- UT ^ MEv for some MEv. Moreover, if both sides hold, then there 
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exists a surjective total function 0i from C onto the set of all model families 
consistent with T', and such that MEv = XE G C • 6i{E)a- 

If h ASP :: /SP, then the left side of the above equivalence holds, hence, 
so does the right one. Then, using one direction of Lemma 5.10, we see that 
indeed MEv{E) G {SPj for all E eC. 

If, on the other hand, h ASP ^ MEv^ then the right side of the above 
equivalence holds, and MEv{E) G {SP} for all E ^ C. Then, using the other 
direction of Lemma 5.10, we see that h ASP :: SP. □ 




6 



Specification Library Calculus 



The aim of the proof calculus for libraries is to capture the well-formedness 
of a library in terms of proof rules. While the static semantics of libraries 
already has the format of such rules, the model semantics has not - it is based 
on set-theoretic notions, and one would have to use to the rules of set theory 
to reason about it. We here sketch direct calculus rules instead. 

The proof calculus for libraries is based on the proof calculi for basic, struc- 
tured and architectural specihcations developed in the preceding chapters. 

A library is correct if: 

• the static semantics of the library succeeds (Chap. where 

• for each structured specihcation encountered in the static semantics of 
the library, the verihcation semantics (Sect. 4.7) for the structured speci- 
hcation succeeds, resulting in a development graph (<S, T/z), and moreover 
S \- Th according to the proof rules for development graphs (Sect. 4.4), 

• for each architectural specihcation encountered in the static semantics of 
the library, the extended static semantics (Sect. 111:5.6) for the archi- 
tectural specihcations succeeds, the induced amalgamability conditions 
can be discharged^, and the induced proof obligations (which are be- 
tween structured specihcations) collected by the architectural proof calcu- 
lus (Sect. 5.3) can be discharged using the calculus of development graphs 
(Sect. 4.4). 

For tool purposes, it is interesting to compute a single development graph 
and set of proof obligations from a library, such that the library is correct 
if the static semantics succeeds and the proof obligations can be discharged 
with the calculus for development graphs given in Sect. 4.4. This goal can 
be achieved by introducing a uniform format for a verihcation semantics for 
LIB- ITEMS, extending the one for structured specihcations given in Sect. 4.7. 
We sketch below how this could be done, using the material of the previous 

^ This can be done via enriched Casl or the so-called cell calculus, see Sect. 111:5.6. 
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chapters. Based on this, the verihcation semantics for LIB-DEFNs is easy. The 
verihcation semantics collects all the proof obligations that arise in a library. 

The verihcation semantics for libraries will be based on verihcation global 
environment: 

An verihcation global environment 

T5,(5,T/z) = (05, Vs, w4s, 7^), (5, T/z) consists of a development graph 
(S^Th) and hnite functions from names to the verification denotations of 
generic specihcations, views, architectural specihcations and unit specihca- 
tions (cf. Chap. 

• Qs • SpecName ^ VerGenSig 

• Vs : View Name ^ VerViewSig 

• As : ArchSpecName ^ VerArchSig 

• Tg : UnitSpecName ^ VerUnitSig 

The domains VerGenSig and VerViewSig have been dehned in Sect. 4.7, as 
well as the context requirements on the corresponding parts of the global envi- 
ronment. We now introduce the semantic domains VerArchSig and VerUnitSig. 
They are basically obtained by taking their non- verihcation counterparts from 
Chap. III:5 and replacing signatures by development graph nodes. This means 
that all the introduced concepts have a meaning only relative to a develop- 
ment graph, and this is the development graph from the verihcation global 
environment. The requirements from Chap. III:5 are imposed here as well, 
with the signatures being those obtained from the nodes by looking up their 
associated signatures in the development graph. 



(7Vi,...,7V^ 

or C 

7Vi,...,7W^7V 
or N^N C 
UN e 
{nCus) e 
Cs e 

{Cs,U^) or AU e 



VerCompSig = Node'^ 

VerParUnitSig C VerGompSig x Node 
VerUnitSig = VerParUnitSig U Node 
VerImpUnitSig C Node x VerParUnitSig 

VerUnitGtx = UnitName ^ {VerImpUnitSig U Node) 
VerArchSig = VerUnitGtx x VerUnitSig 



Ts, (5, Th) h LIB-ITEM Pfi {S', Th') 

Pfi {S' ,Th') is a verihcation global environment extending Pg, {S,Th). 

The rules for SPEC-DEFN and VIEW-DEFN have been spelled out in Sect. 4.7. 
The rules from UN IT- SPEC-DEFN can be obtained by a straightforward adap- 
tion of the static semantic rules for unit specihcations in Sect. 111:5.4. The 
rules for ARCH- SPEC-DEFN are obtained from the rules of the extended static 
semantics for architectural specihcations (Sect. 111:5.6) and the architectural 
proof calculus (Sect. 5.3) in the following way. The rules follow those from 
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the extended static semantics, but with verihcation contexts instead of dia- 
grams, and with resulting specihcations for unit expressions, as in the architec- 
tural proof calculus. Moreover, signatures have to be replaced by development 
graph nodes, as in the transition from the static semantics to the verihcation 
semantics for structured specihcations. Any assumptions involving the ^ re- 
lation between structured specihcations occurring in the rules of Sect. 5.3 
are replaced by theorem links between the corresponding development graph 
nodes. 



h LIB-DEFN (5, Th) 

i^ 5 , (S^Th) is a verihcation global environment. 

Rules very similar to those in the semantics of libraries (Chap. 

Once this program is carried out, we arrive at the following 

Theorem 6.1. A library is well- formed aeeording to the statie and model se- 
manties if the verifieation semanties sueeeeds and all the theorem links in the 
delivered development graph ean he diseharged. (The only if direetion does not 
hold due to the various sourees of ineompleteness mentioned in Chap. 1. 

From structured calculus: 

This verihcation semantics can be shifted to the level of Casl libraries in 
the same way as the ordinary static (and model) semantics. Just note that a 
new library starts with an empty global environment. The empty verihcation 
global environment consists of four empty maps and a development graph 
consisting just of one node (called 0) with signature 0 and a set of axioms 0. 

Theorem 6.2. If 

h LIB-DEFN > {LN,Ts), 

then there is some Tj, (<S, Th) with strip{T^) = Tg and 
h LIB-DEFN {LN, T^, (5, Th)), 



and viee versa, if 

h LIB-DEFN {LN, T^, {S, Th)), 

then 

h LIB-DEFN > {LN, strip{T^)) 

Moreover, in this ease, the following are equivalent 

1. there is a model global environment Tj^ with h LIB-DEFN ^ Tr^. 

2.S^ Th. 

Furthermore, if these two equivalent eonditions hold, then F^ is eompatible 
with Fm. 
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Introduction 



This part of the Casl reference manual describes a library of elementary 
specihcations called the Basic Datatypes. This library has been developed 
with two main purposes in mind: on the one hand, it provides the user with 
a handy set of off-the-shelf specihcations to be used as building blocks in 
the same way as library functions in a programming language, thus avoiding 
continuous reinvention of the wheel. On the other hand, it serves as a large 
reservoir of example specihcations that illustrate both the use of Casl at the 
level of basic and structured specihcations. The specihcation methodology 
behind the Basic Datatypes is described in [57]. 

The name Basic Datatypes is actually slightly misleading in that there are 
both monomorphic specihcations of typical datatypes and loose specihcations 
that express properties e.g. of an algebraic or order theoretic nature. The hrst 
type of specihcation includes simple datatypes like numbers and characters 
as well as structured datatypes (typically involving type parameters) such as 
lists, sets, arrays, or matrices. The second type of specihcation is oriented more 
closely towards traditional mathematical concepts; e.g. there are specihcations 
of monoids and rings, as well as equivalence relations or partial orders. The 
library is structured partly along precisely these lines; an overview of the 
sublibraries is given in Section 1.1. 

In the design of a library of basic specihcations, there is a certain amount 
of tension between the contradicting goals of 

• keeping specihcations simple and readable also for novice users, and 

• making them economical, concise, and amenable for tool support. 

This concerns in particular the degree of structuring, with parametrized spec- 
ihcations being most prominent as on the one hand increasing elegance and 
reusability and on the other hand placing on the reader the burden of looking 
up imported specihcations and keeping track of signature translations. With 
the exception of the library of numbers, the libraries exhibit a certain bias 
towards more extensive use of structuring operations. Several measures have 
been undertaken to enhance readability of the specihcations, one of them being 




364 V:1 Introduction 



the facility to have the signatures for the specihcations in a library explicitly 
listed by the Casl tools. 

The specihcations make use of a set of annotations concerning semantics 
and operator precedences; moreover, we use the Casl syntax for literals. The 
details of these annotations and syntax extensions are explained in Chap. 11:5 
of the Casl Language Syntax. 

The material is organized as follows. After the above-mentioned descrip- 
tions of the component libraries (Section 1.1), the actual content of the li- 
braries is presented in Chapters 2 through 11. Chap. 12 contains graphical rep- 
resentations of the dependencies between the specihcations. Moreover, there 
is an index of all library and specihcation names at the end of the book. 

Acknowledgement 
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lar, we wish to thank Hubert Baumeister, Ulrich Berger, Bernd Krieg- 
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Giuseppe Scollo, and John Tucker for refereeing the hnal draft of the libraries. 
Furthermore, special thanks to Klaus Luttich for implementing the automatic 
translation from Casl to pretty printed UTp;X, as well as optimizing the de- 
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1.1 A Short Overview of the Specified Datatypes 

The libraries of basic datatypes have been successfully parsed and statically 
checked with the Bremen Casl tool set (CATS), as well as with the Hetero- 
geneous tool set (Hets). Both tools as well as an ASCH-format version of 
libraries of basic datatypes are available on the CD-ROM coming with this 
volume. The latest versions always can be obtained at 

http : //www. cof i . inf o/Tools 

We recommend to use the Hets tool in order to obtain a graphical overview 
over the specihcations in the libraries and also to inspect their signatures. 
A quick introduction to Hets can be found at the above URL and also in 
Chap. 10 of the Casl User Manual [5]. 

The collection of basic datatypes presented here consists of the following 
libraries: 

• Numbers 

• RelationsAndOrders 

• Algebra_I 

• SimpleDatatypes 
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• StructuredDatatypes 

• Graphs 

• Algebra_II 

• LinearAlgebra_I 

• LinearAlgebra_II 

• MachineNumbers 

each of which is described in detail in the following paragraphs. The graph of 
dependencies among the libraries is shown in Fig. 1.1. 




1.2 The Library Basic/Numbers 

This library, cf. Chap. 2, provides monomorphic specifications of natural num- 
bers, integers and rational numbers, as well as rational numbers with syntactic 
constructs for decimal fractions. 
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To a certain extent, the real numbers can also be addressed in Casl, 
although a full specihcation is difficult due to the fact that completeness is 
a higher-order axiom. In [59], a weak theory of the real numbers is specified 
and compared to other approaches possible in a similar setting. But as none of 
these approaches leads to a ‘basic off-the-shelf specification’, we have refrained 
from including the real numbers in the library of Basic Datatypes. 

In the specification Nat, the natural numbers are specified as a free type, 
thus ensuring that all natural numbers can be constructed from 0 and the 
successor operation suc^ and that all terms formed from these two operations 
are distinct. Consequently, all predicates and operations over the sort Nat of 
natural numbers are defined by recursion over the two constructors. 

In addition to the representation in terms of 0 and suc^ the usual decimal 
representation of naturals is introduced in order to provide a more convenient 

syntax. To this end, the parsing annotation %number @@ is declared 

at the beginning of the library; this means that any sequence of digits is to be 

read as if the function @@ were placed in between. The semantics of 

the function @@ is then determined by the axiom %{decimal _def)%. 

Note that the names for the partial operations subtraction — ? and 

division /? include a question mark. This is to avoid overloading with 

the total operations — on integers and / on rationals, which 

would lead to inconsistencies as both these specifications import the specifi- 
cation of natural numbers. 

The introduction of the subsort Po5, consisting of the positive integers, 
gives rise to certain new operations, e.g. 

* : Pos X Pos Pos^ 

whose semantics is completely determined by overloading. 

The specification Int of integers is built on top of the specification of 
naturals: integers are defined as equivalence classes of pairs of naturals written 
as difierences, where %{equality _Int)% determines the equivalence relation 
on these pairs. The sort Nat is then declared to be a subsort of Int. Finally, 
the axiom %{N at2Int _embedding)% characterizes the embedding of naturals 
into integers. 

The definition of the predicates and operations on integers usually covers 
the whole domain of integers; hence, concerning consistency, one has to show 
that they do not contradict the axioms for naturals, to which the relevant 
operations are related by overloading. 

Besides the division operator /? , the specification Int also pro- 

vides the function pairs div/mod and quot/rem^ respectively, as constructs 
for division: 

• The functions div and mod are motivated by the residue class ring Z^, 

m G Z\{0}, where the residue classes are represented by elements of 

{0, 1, . . . , m — 1}. In this notation, the operator mod computes the residue 
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class n mod m in of an element n G Z. The division operator div is 
related to mod by: 

\!n ^7L^m ^ ^\{0} n = (n div m) * m + (n mod m) 

This equation is solved by putting n div m := \ n/m \ , where [ J denotes 

the largest integer lower bound. Thus one obtains the following results: 



b div 3 = 1 


5 mod 3 = 2 


—5 div 3 = — 2 


—5 mod 3=1 


5 div -3 = -1 


5 mod —3 = 2 


—5 div — 3 = 2 


—5 mod —3=1 



• Another way to deal with division is to require of the remainder operator, 
now called rem, that 



\n rem m\ = |n| rem \m\ 

for all integers n, m (which doesn’t hold for the operator mod). To this end, 
the representative has to be chosen depending on the sign of n: Choose 
the representative from the set {0, 1, . . . , m — 1} if n > 0, and from the 
set {0, — 1, . . . , — (m — 1)} if n < 0. The division function quot is then 
determined by requiring 

Vn G Z, m G Z\{0} : n = {n quot m) * m + (n rem m). 

For this division operator, we have 

\n quot m\ = |n| quot \m\. 



Some example values: 



5 quot 3 = 1 


5 rem 3 = 2 


—5 quot 3 = — 1 


—5 rem 3 = — 2 


5 quot —3 = — 1 


5 rem — 3 = 2 


—5 quot — 3 = 1 


—5 rem —3 = —2 



There is no need to define a new parsing annotation for decimal repre- 
sentation of integers, as the one for naturals carries over. Positive integers 
are first parsed as a natural and then subjected to the implicit embedding 
from naturals to integers. The same holds for negative integers, where just 
the unary minus has to be applied after the embedding. 

The specification Rat of rational numbers follows the same scheme as the 
specification of integers discussed above. This time, the specification Int is im- 
ported. The rationals are then defined as equivalence classes of pairs consisting 
of an integer and a positive number written as quotients. % {equality _Rat)% 
determines the equivalence relation on these pairs. The sort Int is then de- 
clared to be a subsort of Rat. Finally, the axiom %{Int2Rat _embedding)% 
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characterizes the embedding. Note that thanks to Casl subsorting, the dec- 
laration of the operation 



/ : Rat X Rat -^1 Rat 

allows writing rationals also as pairs x/y of arbitrary integers x and y ^ 0. 

Again, the dehnition of the predicates and operations on rationals usually 
covers the whole domain of rationals, i.e. concerning consistency one has to 
show that they do not contradict to the axioms for naturals and integers, to 
which they are related by overloading. 

The specihcation DecimalFraction extends the rationals by syntac- 
tic sugar that allows writing rationals in the form of decimal fractions like 
11.02F^— 3 or —0.2. To this end, the library Basic/Numbers includes the 

parsing annotation %floating. Here, the function ::: evaluates the 

decimal point, while the function E is used for the exponentiation ^E\ 

The specihcation DecimalFraction then provides axioms for both of these. 
Note how the different parsing annotations cooperate with each other. The 
numbers to the left and right of the decimal point are parsed as naturals and 
then turned into a rational by evaluating the function replacing the decimal 
point. The function replacing the is applied to the result. 

The main order-theoretic and algebraic properties of the numbers spec- 
ihed in this library are expressed in terms of Case views. The library 
Basic/RelationsAndOrders, cf. Chap. 3, includes views that state that 
the specihed naturals, integers, and rationals are totally ordered. In the library 
Basic/ Algebra_I, cf. Chap. 4, views can be found expressing e.g. that the 

naturals with + and 0 or * and 1, respectively, satisfy the 

axioms of a commutative monoid, that the integers are an integral domain, 
and that the rationals form a held. 



1.3 The Library Basic/RelationsAndOrders 

This library, cf. Chap. 3, provides specihcations for various types of relations. 
Among the specihed structures are rehexive, symmetric, and transitive rela- 
tions and equivalence relations, partial and total orders, as well as Boolean 
algebras. For some of these, the library offers extended versions. 

Datatypes involving completeness properties, like directed complete partial 
orders or complete lattices, are omitted here. Their specihcation would require 
higher-order axioms that are not expressible in Case. (It would, however, be 
possible to specify cj-complete partial orders.) 

The specihcations concerning the basic structures are naked textbook- 
style dehnitions. These are then extended by adding typical predicates and 
operations from the respective mathematical theories. Such an extended ver- 
sion ExtX takes the specihcation X as a parameter. In order to avoid ex- 
cessive verbosity in cases where instantiations do not involve renaming, pre- 
instantiated parameterless specihcations RichX are included; in particular. 
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RichX specifies the same model class as ExtX. For instance, the specifica- 
tion TotalOrder adds an axiom stating comparability of all elements to the 
specification of partial orders. Its extended version ExtTotalOrder then 
provides (among others) the additional operations min and max, which are 

defined in terms of the < predicate stemming from the specification 

TotalOrder in the parameter. RichTotalOrder is identical to ExtTo- 
talOrder, except that it does not have a parameter. 

In the extended versions, concepts are often added independently of each 
other. This is refiected by the use of the Case union operator ’and’ instead of 
the extension operator ’then’. For example, adding the operators m/and sup 

to partial orders is independent of the definition of the predicate < 

on top of < . 

The library concludes with a collection of views. These state that the 
numbers specified in the library Basic/ Numbers are totally ordered, and 
that a Boolean algebra carries also the structure of a partial order. 



1.4 The Library Basic/ Algebra l 

In this library, cf. Chap. 4, specifications of basic algebraic structures are col- 
lected. These specifications, like those in Basic/RelationsAndOrders, are 
usually split into two parts, one that provides the necessary signature and ax- 
ioms in as simple a way as possible, and a second, parametrized part labelled 
Ext. . . which contains derived operations and predicates. Typical examples 
are power operations with natural or integer exponents, the inverse operation 
for groups, and predicates concerning divisibility and invertibility in rings. 
Moreover, the extended specifications contain theorems, intended to be deriv- 
able from the axioms, in the shape of formulas annotated as implied. As in the 
library RelationsAndOrders, the extended specifications are pre-instantiated 
under the name Rich. . . ; these specifications may be found near the end of 
the library. Any views into the extended specifications are repeated for the 
pre-instantiated forms, since views cannot be defined in terms of other named 
views in Case. 

The hierarchy of algebraic structures presented begins with monoids, con- 
tinuing via groups and Abelian groups to rings, integral domains, and fields. 
At the end of the library, a number of views are given that subsume concepts 
from the numbers library under the appropriate algebraic concepts, e.g. a view 
IntegraeDomain_in_Int which states that the integers with their usual 
addition and multiplication form an integral domain. By contrast, several 
views that express theorems about the algebraic concepts introduced are given 
directly after the concept they concern. E.g., there is a view PreOrder_in_ 
ExtCRing stating that the elements of a commutative ring are pre-ordered 
by the divisibility relation, located adjacently to the (extended) specification 
of commutative rings. 
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A feature that requires a word of explanation is the fact that the specih- 
cation of helds is actually split into three parts, namely, ConstructField, 
Field, and ExtField. The reason for this is that an extra sort of nonzero 
elements is needed to specify the multiplicative group structure of a held; 
since this sort is not regarded as a part of the basic signature of a held (this 
signature should be identical to that of a ring, i.e. consist of one sort and 
two unary and two binary operations), it is introduced in ConstructField, 
then hidden in Field, and hnally reintroduced in ExtField by instantiating 
ExtCommutativeRing with ConstructField as argument. 

The specihcations ExtRing and ExtCommutativeRing contain, among 
other things, elements of divisibility theory in rings. In ExtRing, a unit pred- 
icate isUnit and an irreducibility predicate isirred are introduced, along with 
subsorts N onZ ero[Elem\^ RU nit[Elem\^ and Irred[Elem\ representing non- 
zero, unit, and irreducible elements. Recall that an element of a ring is a unit 
if it has a multiplicative inverse, and that a non-unit element is irreducible 
if it cannot be decomposed into two non-unit elements. The identity, multi- 
plication, and additive inverse operations are given additional prohles stating 
that they restrict to unit elements; identity and multiplication indeed make 
the set of unit elements into a group, a fact which is expressed by the view 
Group_in_ExtRing. The specihcation ExtCommutativeRing addition- 
ally provides a nullary predicate hasNoZeroDivisors^ detecting whether or 
not there are divisors of zero, and binary divisibility and associatedness re- 
lations; recall that two elements of a commutative ring are called associated 
if they differ only by an invertible factor. The fact that two elements are 
associated iff they are mutually divisible is stated as a theorem. Moreover, 
there are two views PreOrder_in_ExtCRing (see above) and EqRel_ 
in_ExtCRing, with the latter stating that associatedness is an equivalence 
relation. 



1.5 The Library Basic/SimpleDatatypes 

This library, cf. Chap. 5, provides unstructured datatypes like Booleans and 
characters. 

The Booleans are specihed in Boolean, are shown to be a Boolean algebra 
(view Boolean Algebra_in_ Boolean) and then enriched with the usual 
Boolean algebra operations (using the specihcation ExtBoolean Algebra). 
The characters are specihed in Char. They are dehned to be the subset 0 
. . . 255 of the natural numbers, and then constants for different representations 
(ASCII, decimal, octal, hexadecimal) are introduced. 

1.6 The Library Basic/StructuredDatatypes 

This library, cf. Chap. 6, provides specihcations that formalize structuring con- 
cepts of data as used e.g. for the design of algorithms or within programming 
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languages. Its main focus is data structures like (finite) sets, fists, strings, (fi- 
nite) maps, (finite) bags, arrays, and various kinds of trees. But it also covers 
some elementary constructions like the encapsulation of data within a ‘maybe’- 
type or arranging data as pairs. Common to all these concepts is that they 
are generic. Consequently, all specifications of this library are parametrized. 
Furthermore, in all specifications of this library the body of the specifications 
monomorphically extends the given parameters and imports. 

Arbitrary sets, maps and bags, or streams are omitted. Their monomorphic 
specification would require higher order axioms not available in Casl. Non- 
monomorphic first-order specifications of these types are not included, as the 
answer to the question which operations to provide and which non-standard 
models to accept would depend too much on the particular context. 

Finite sets, finite maps and finite bags are specified in terms of observers: 
given a generated sort, an operation or predicate is introduced in order to de- 
fine equality on this sort. Concerning finite sets, equality on the sort Set[Elem] 

is characterized using the predicate e , see the specification Generate- 

Set. Finite maps, i.e. elements of the sort Map[S, T], are considered to be 
identical if their evaluation under the operation eval yields the same result, cf. 
the specification GenerateMap. In the specification GenerateBag, those 
elements of sort Bag[Elem] are identified that show the same frequency (ob- 
served by the operation freq) for all entries. 

The specification PowerSet works solely with Case subsorting and over- 
loading; no defining axiom is needed. This is achieved by the subsort def- 
initions for Powers et[X] and Elem[X]. Besides determining the elements 
of the respective sorts, these definitions also induce the subsort relations 
PowerSet[X] < Set[Elem] and Elem[X] < Elem. This type system ensures 
that the newly introduced predicates and operations are in overloading rela- 
tion with the identically named predicates and operations of the specification 
Set [Elem], and hence are just restrictions of those. 

Finite fists are specified in terms of a free datatype. In the specification 
GenerateList, fists are built up from the empty fist by prefixing. The reverse 
construction, i.e. describing fists as a type that consists either of the empty 
fist or a fist followed by an element, is added in the specification List as an 
implied consequence. That is, the specification List makes both approaches 
and their corresponding induction principles available. The predicates and 
operators, however, are all defined using the first approach. The parsing an- 
notation %list at the beginning of the library allows to write fists in the more 
convenient syntax ‘[ti, . . . ,Xn]’ besides :: ... :: Xn :: []’ as provided by the 
constructors. 

The specification Array includes the condition min < max as an ax- 
iom in its first parameter. This ensures a non-empty index set. Arrays are 
defined as finite maps from the sort Index to the sort Elem^ where the typical 
array operations evaluation and assignment are introduced in terms of finite 
map operations. Finally, revealing the essential signature elements yields the 
desired datatype. 
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The library concludes with several specihcations concerning trees. There 
are specihcations covering binary trees (BinTree, BinTree2), trees with 
a possibly-different branching at each node (NTree, NTree2), and k- 
branching trees (KTree, KTree2). Each of these branching structures can 
be equipped with data in different ways: either all nodes of a tree carry data 
(as it is the case in BinTree, NTree, and KTree), or just the leaves of 
a tree have a data entry (as in BinTree2, NTree, and KTree). Note the 
slightly more complex type systems needed in the latter case. 

In GenerateNTree and GenerateNTree2, it is necessary to spec- 
ify both the datatype of trees as well as the datatype of lists modeling the 
branching together in one free type construct in order to avoid unintended 
models. To provide the usual operations on lists, the specihcation List is 
imported later in NTree and NTree2, resp. Note that NTree2 does not 
include empty branching, while in NTree an empty list of branches charac- 
terizes a leaf node. The /c-branching trees are then introduced as subsorts of 
the NTrees. 

The abstract properties of the specihed concepts are expressed in terms of 
views, in this library mostly to be found directly after the specihcation. For 
example, hnite sets carry the structure of a partial order, hnite power sets are 
Boolean algebras, and lists form a monoid. 



1.7 The Library Basic/Graphs 

This library, cf. Chap. 7, provides a specihcation of directed graphs, as well as 
operations and predicates on graphs, like paths, transitive closure, connect- 
edness, n-colorability and planarity. These capture standard notions from the 
literature, see e.g. [18]. 

The specihcation Graph constructs directed graphs inductively by suc- 
cessively adding nodes and edges to an empty graph, using a generated type 
and an explicit characterization of equality. Due to the inductive dehnition, 
only hnite graphs are covered. However, the advantage of this approach is that 
graphs are hrst-class objects, i.e. members of algebras (rather than algebras 
themselves, as in other approaches). 

The specihcation is parametrized over two sorts, Nodeld and Edgeld. 
These provide the (typically inhnite) vocabularies for node and edge iden- 
tihers. These must uniquely identify nodes and edges. Since we allow only 
hnite graphs, in a given graph, only hnitely many identihers of the vocabular- 
ies are actually used. If multiple edges with the same label are needed, Edgeld 
should be chosen as isomorphic to a product (e.g. Label x Ini). 

The operation addNode is total - if a node that is already present in the 
graph is added twice, nothing happens. By contrast, addEdge is partial: this 
is because an edge always has to be added together with its source and target 
node, and adding an edge twice (with possibly different source and target 
nodes) is prohibited. 




V:1.7 The Library Basic/Graphs 373 



The specification provides predicates to check whether a node or an edge is 
in the graph, as well as a predicate checking whether an edge goes between two 
particular nodes. The operations source and target are partial, because they 
act on the global vocabulary of edge identifiers, while a given graph usually 
contains only some of these. Note that source and target are undefined for 
the empty graph, and this undefinedness is inherited via the strong equations 
defining souree^ which yields that souree and target are also undefined if the 
edge identifier given in the first argument is not present in the graph given by 
the second argument. 

The specification RichGraph provides further operations (for removing 
nodes and edges) as well as a bunch of graph-theoretic predicates {loopFree^ 
simple^ subgraphOf ^ eomplete^ eliqueOf ^ maxCliqueOf). Note that removing 
a node from a graph also entails removing all edges having this node as source 
or target node. 

The specification GraphToSet provides a means to change the graph rep- 
resentation by mapping the inductively generated graphs to the more common 
mathematical definition: a graph consists of a set of nodes, a set of edges, and 
source and target functions going from edges to nodes. 

A subsort of symmetric graphs is introduced in SymmetricGraph. Since 
these can be seen as a representation of undirected graphs, we also intro- 
duce restrictions of the graph operations to this subsort. The specification 
SymmetricGlosure defines the symmetric closure of a graph. 

In the specification Paths the paths in a graph as well as the transitive 
closure of a graph are specified. PathGraphs are defined as graphs over lists of 
edge identifiers. The transitive closure of a graph is then the minimal transitive 
super-PathGraph of that graph. A path in a graph is defined to be an edge 
in the transitive closure. 

Further concepts are defined in a straightforward manner on top of these 
basic notions. Trees are acyclic graphs with a root node such that each node 
is reachable via a unique path from the root. Connectedness and acyclicity 
can be elegantly expressed using (symmetric) transitive closure. A spanning 
tree is a tree subgraph that has the same nodes as the graph. 

Finally, some notions concerning undirected graphs (represented as sym- 
metric graphs) are defined. A symmetric graph is said to have a cycle only 
if the cycle is non-trivial, i.e. does not exploit the fact that for each edge 
there also is an edge in the opposite direction. Symmetric trees are connected 
graphs that are acyclic in the symmetric sense. 

The specification GraphGolorability defines n-colorable and bipartite 
graphs. 

Assuming a weight function on edge identifiers, the specification Short- 
estPaths provides a loose specification of shortest paths in a graph. For a 
source and a target node, the shortest path function is only defined if there is 
at least one path from the source to the target. 

Since also homomorphisms between graphs over different node and edge 
vocabularies are interesting, the specification GraphHomomorphism is 
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parametrized over two pairs of node and edge vocabulary, and for each pair, 
the specihcation Graph is instantiated (and the resulting sort Graph is re- 
named differently for the two instantiations). 

Pre-homomorphisms just collect the data of graph homomorphisms, ba- 
sically consisting of source and target graph and of the hnite maps between 
nodes and edges. The subsort Horn consists of those pre-homomorphisms that 
actually satisfy the homomorphism condition. 

A minor of a graph is something that can be homomorphically mapped to 
the transitive closure. This concept is formalized in the specihcation Minor. 

The library continues with the specihcations of specihc graphs: K5 pro- 
vides the complete graph over hve nodes. Note that the K5 is captured by 
the constant kb written lower case, since constants generally are written lower 
case in the library of Basic Datatypes (cf. [57]). K3_3 introduces the graph 
consisting of two copies of three nodes, such that two nodes are linked by 
an edge iff they stem from different copies. Then, Planar dehnes planar 
graphs using the Kuratowski characterization: K5 and K3_3 must not occur 
as minors. 

Finally, the specihcation NonUniqueEdgesGraph provides graphs with 
edge labels that need not be unique (note that with ordinary graphs, each edge 
may be inserted only with one pair of source and target nodes). The trick is 
to turn edges labels into unique edges by coupling them with the source and 
target node. 



1.8 The Library Basic/ Algebra_II 

This library, cf. Chap. 8, contains slightly more advanced algebraic concepts, 
in particular 

• monoid and group actions on a space, 

• ring theoretic notions such as euclidian and factorial rings, 

• polynomials, and 

• two views exhibiting the datatypes of lists and bags as free monoids and 
free commutative monoids, respectively. 

At several points, use is made of structured datatypes. E.g., factorial rings 
require bags for the specihcation of factorizations (e.g., factorizing an integer 
amounts to stating how often it is divisible by any given prime), and poly- 
nomials are represented as lists of coefficients. For monoid actions, the use 
of parametrization has been restricted to the involved monoid, rather than 
parametrizing over the space as well, in order to keep the specihcations read- 
able. 

Dehning the degree function for polynomials requires an extension of the 
integers by — oo (since by the usual convention, deg(G) = — oo); the corre- 
sponding specihcation IntIneinity is provided here as well. Polynomials (in 
one variable) can, of course, be specihed very concisely as the free algebra 
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on one generator using Casl’s free-construct; this is stated in the library 
Basic/Linear Algebra_II by means of a view. 

For the same reason as for fields, the specification of factorial rings is split 
into three parts (cf. 1.4); the machinery required to arrive at the somewhat 
involved statement in ConstructFactorialRing that each element of a 
factorial ring has an essentially unique factorization into irreducible elements, 
where ‘essentially unique’ means unique up to associatedness of the factors, is 
temporarily discarded in FactorialRing. Several views are provided, stating 
e.g. that integers and polynomials, respectively, form euclidian rings and that 
euclidian rings are factorial. 

In more detail, euclidian rings are defined as admitting division with re- 
mainder, where division strictly decreases a measure function delta. In the 
representation of polynomials as fists of coefficients, the head of the fist rep- 
resents the constant coefficient (i.e. that of X^). In order to obtain a unique 
representation, fists that end with a 0 are excluded; e.g., 1 is represented by 
[1], and 0 is represented by []. This choice of representatives is reflected in a 

special constructor ::: which behaves like the usual fist constructor 

except in cases where this would lead to a fist with leading coefficient 0. Note 
that a ::: p = a-\-p^ X ^ where a is an element of the underlying ring and p is a 
polynomial. Addition and multiplication of polynomials are defined by recur- 
sion over this special constructor. The view which identifies polynomial rings 
as being euclidian requires casting the (normally Zqo - valued) degree function 
to natural number values in order to match the measure function delta in 
the specification of euclidian rings; the downcast is undefined for the zero 
polynomial, which is explicitly allowed for euclidian rings. 

The extended specifications for monoid and group actions, respectively, 
mention a binary orbit relation connected on the underlying space, where x 
is connected to y iff it is taken to y by some element of the monoid. This 
relation is in general a pre-order, and an equivalence relation for group ac- 
tions (the arising equivalence classes are usually called orbits), which facts are 
expressed by the views PreOrder_in_ExtMonoidAgtion and EqRel_ 
in_ExtGroupAgtion, respectively. 



1.9 The Library Basic/Linear Algebra l 

This library, cf. Chap. 9, provides elementary concepts from linear algebra 
such as vector spaces and bases. Moreover, there are ‘computational’ specifica- 
tions for tuples of vectors (i.e. finite powers of vector spaces), column vectors, 
and matrices, equipped with the usual operations such as scalar product, ma- 
trix multiplication, and determinant. These are related to the abstract notions 
of vector space etc. via suitable views. 

Using predefined concepts from the algebra library, the definition of vec- 
tor spaces can be kept very concise: a vector space is an action of the multi- 
plicative monoid of a field on an Abelian group, subject to two distributivity 
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axioms. The specification of a base of a vector space requires the introduc- 
tion of a technical sort BaseLC for linear combinations of base elements. 
This sort is, as can by now be considered established practice, introduced in 
ConstructVSWithBase and hidden in VSWithBase. The advantage of 
having to specify only a base, but not a sort of linear combinations, is illus- 
trated on several occasions where views are provided from VSWithBase to 
e.g. matrices or vectors. 

More precisely, the concept of a linear combination is introduced in the 
auxiliary specification VECTORS paceLC; formally, a linear combination is 
a finite map from vectors to scalars including zero. An evaluation predicate 
eval for linear combinations and a test for zero linear combinations are defined 
recursively. 

The specifications of tuples, vectors and matrices are comparatively lengthy 
due to the fact that concrete functions on them need to be defined recursively, 
occasionally using auxiliary functions that are later hidden. In fact, the num- 
ber of auxiliary signature items in the specification of matrices is so large that 
they are more conveniently hidden via a local specification, rather than by an 
explicit hiding statement. 

For example, n-tuples of vectors are defined as arrays, indexed from 1 
to n; operations on them are defined in terms of the array access operation 

! (cf. Section 1.6). There is a sum operation for vector tuples; the 

recursive definition of this function requires an auxiliary function auxsum 
which adds all elements up to a given index. Similarly, the definition of the 

scalar product ( || ) requires auxiliary functions auxmult and auxprod; 

the former is component-wise multiplication of vectors, and the second plays 
a role analogous to that of auxsum in the definition of a function prod that 
multiplies all scalars in a vector. Recall that the scalar product is defined by 

n 

{{xi, . . . ,Xn)\\{yi, . . ■ ,yn)) = y^^Xjyj. 

i=l 

The datatype of matrices is defined via tuples of vectors, i.e. in the end via 
two-dimensional arrays, with elements accessed by applying the array access 
function ! twice. A transpose operation and elementary matrices are defined 
via the access operation; recall that a matrix is elementary iff exactly one of 
its entries is 1 and all others are 0. The determinant of a matrix is defined by 
the Leibniz formula 

det(ay) = y]e(7r)a„(i), 

where tt ranges over all permutations of the set {!,..., n} and e(7r) is the 
sign of 7T. This requires a separate specification of the n-th symmetric group 
that includes the sign function. A permutation is represented by the array 
containing its graph; the sign function is specified as the unique nontrivial ho- 
momorphism from the symmetric group into the multiplicative group { — 1,1}. 
Moreover, the symmetric group is supplied with an enumeration function perm 
defined on the set {1, . . . , n\}. 
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At the end of the library, several views are provided that exhibit the sets of 
vectors and matrices as vector spaces equipped with standard bases. Similarly, 
there is a view stating that every field is a vector space over itself, with the 
multiplication of the field as scalar multiplication; this view is located earlier 
in the library, since it is needed in the specification Construct Vector. 
Moreover, there is an example for the use of views as ‘higher order theorems’: 
under the axiom of choice (which is assumed for the semantics of Case, see 
Chap. every vector space has a base; this is expressed by means of the 

view VSWithBase in VectorSpace. 



1.10 The Library Basic/Linear Algebra ll 

In this library, cf. Chap. 10, we present one advanced notion omitted from the 
elementary linear algebra library, namely that of algebras over a field, i.e. vec- 
tor spaces equipped with a compatible ring structure. Notably, the extended 
specification of /c-algebras contains an evaluation operation for polynomials 

over /c, defined recursively using the special fist constructor ::: for 

polynomials that avoids 0 as leading coefficient. Moreover, we have included 
two views stating that a vector space with a given base is free over that base, 
and that the polynomial ring in one variable over a field k is the free /c-algebra 
over a one-element set. Two specifications are introduced expressly for this 
purpose, namely, FreeVectorSpace and Free Algebra. As indicated by 
the name, these specifications make use of Case’s structured free-construct; 
comparing them with the ‘standard’ ones gives a good feel for the expressive 
power of that construct. 



1.11 The Library Basic/MachineNumbers 

This library of machine numbers, cf. Chap. 11, contains specifications of those 
subtypes of the naturals and the integers that are used on actual machines. 

The specifications CARDINAL and INTEGER provide subtypes of nat- 
urals and integers consisting of those numbers that have a binary representa- 
tion within a given word length. Operations on these data types are partial 
restrictions of the usual operations on naturals and integers - they are unde- 
fined if the word length is exceeded. 

The specification TwoComplement provides a ‘cyclic’ version of bounded 
integers that corresponds to the common two complement representation of 
integers used in many programming languages. Operations are total here - 
the successor of the maximal positive number fitting in the word length is the 
minimal negative number. 

The Ext versions of the specifications add minimum and maximum oper- 
ations by instantiating ExtTotalOrder. 




2 



Library Basic/Numbers 



library Basic/Numbers version 1.0 

%authors(M. Roggenbach <csmarkus@swansea.ac.uk>, T. Mossakowski, 
L. Schroder) % 

%date : 18 December 2003 

%{ This library provides specifications of naturals, integers, and 

rationals. Concerning the rationals, the specification Rat includes 
the datatype proper, while the specification DecimalFraction adds the 
notions needed to represent rationals as decimal fractions. }% 

%display( <= %LATEX < )% 

%display( >= %LATEX > )% 

%prec({ -? , - , + } < { * , /? , / , 

div , mod , quot , rem })% 

%prec({ * , /? , / , div , mod , quot 

rem } < { " })% 

%prec({- } <> { ^ })% 

%prec({__E__} < 

%left_assoc( + , * , @@ )% 

%number @@ 

%fioating ::: , E 



spec Nat = %mono 

free type Nat ::= 0 \ suc{pre:lNat) 

preds < , > , < , > : Nat x Nat; 

even^ odd : Nat 
ops ! : Nat Nat; 

+ , * , " , mm, max, — ! : 

Nat X Nat Nat; 

— ? , /? , div , mod : 

Nat X Nat -^7 Nat 




380 V:2 Library Basic/Numbers 



%% Operations to represent natural numbers with digits: 



ops 1: Nat = suc{0); 
2: Nat = suc{l); 
3: Nat = suc{2)] 
Jf.: Nat = suc{3)] 
5: Nat = suc(4)'-, 
6: Nat = suc{5)'^ 
7: Nat = suc{6); 
8: Nat = suc{7); 
9: Nat = suc{8)] 



%(l_def_Nat)% 

%(2_def_Nat)% 

%(3_def_Nat)% 

%(4_def_Nat)% 

%(5_def_Nat)% 

%(6_def_Nat)% 

%(7_def_Nat)% 

%(8_def_Nat)% 

%(9_def_Nat)% 



@@ (m: Nat] n: Nat): Nat = m * suc{9) + n 

%(decimal_def)% 



%% implied operation attributes : 

ops + : Nat x Nat Nat^ comm^ assoc^ unit 0; 

* : Nat X Nat Nat^ comm^ assoc^ unit 1; 

min : Nat x Nat Nat^ comm^ assoc; 

max : Nat x Nat Nat^ comm^ assoc^ unit 0 



%implied 

%implied 

%implied 

%implied 



V m, n, r, 5, t: Nat 



%% axioms concerning predicates 

• 0 < n 

• ^ suc{n) < 0 

• suc{m) < suc{n) m < n 
•m>n^n<m 

• m<n4^m<nA^m = n 

• m>n<An<m 

• even{0) 

• even{suc{m)) AA odd{m) 

• odd{m) AA ^ even{m) 



%(leq_defl_Nat)% 
% (leq_ def2 _ Nat ) % 
%(leq_def3_Nat)% 
%(geq_def_Nat)% 
% (less _ def _ N at ) % 
% (great er_ def _ Nat ) % 
%(even_0_Nat)% 
%(even_suc_Nat)% 
%(odd_def_Nat)% 



%(factorial_0)% 
% (factorial_suc) % 
%(add_0_Nat)% 
%(add_suc_Nat)% 
%(mult_0_Nat)% 
% (mult _suc_ Nat )% 
%(power_0_Nat)% 
% (power _suc_Nat)% 
%(min_def_Nat)% 
%(max_def_Nat)% 
%(subTotal_defl_Nat)% 
%(subTotal_def2_Nat)% 
%(sub_dom_Nat)% %implied 
%(sub_def_Nat)% 



%% axioms concerning operations 
• 0 \ = 1 

• suc{n) ! = suc{n) * n ! 

• 0 N m = m 

• suc{n) N m = suc{n + m) 

• 0 ^ m = 0 

• suc{n) ^m = n^m-\-m 

• m "0 = 1 

• m " suc{n) = m * m " n 

• min{m^ n) = m when m < n else n 

• max{m^ n) = n when m < n else m 

• n —\ m = 0 if m > n 

• n —\ m = n —7 m if m < n 

• def m —7 n AA m > n 

• m—7n = r<Am = rNn 
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• def m/7n4^^n=0 Am mod n = 0 

%(divide_dom_Nat)% %implied 

• ^ def m /I 0 %(divide_0_Nat)% 

• {m /? n = r AA m = r ^ n) if n > 0 %(divide_Pos_Nat)% 

• def m div n AA ^ n = 0 %(div_dom_Nat)% %implied 

• m div n = r AA 3 s: Nat •m = n^r-\-sAs<n %(div_Nat)% 

• def m mod n AA ^ n = 0 %(mod_dom_Nat)% %implied 

• m mod n = s AA 3 r: Nat •m = n^r-\-sAs<n 

%(mod_Nat)% 



%% important laws 

• {r-\-s)^t = r^t-\-s^t 

• t^{r-\-s) = t^r-\-t^s 

then %mono 

sort Pos = {p: Nat • p > 0} 
ops 1: Pos = sue{0); 

* : Pos X Pos Pos; 

+ : Pos X Nat Pos; 

+ : Nat X Pos Pos; 

sue : Nat Pos 
then %implies 

y m^ s: Nat 

• min{m^ 0) = 0 

• m = {m div n) * n + m mod n if 

• m " {r s) = m " r ^ m " s 

end 



%(distrl_Nat)% %implied 
%(distr2_Nat)% %implied 



%(l_as_Pos_def)% 



%(min_0)% 
n = 0 %(div_mod_Nat)% 
% (power _ Nat )% 



spec Int = %mono 

Nat 

then %mono 

generated type Int ::= — {Nat; Nat) 

V a, 6, c, d: Nat 

• a— b = e— dAAa-\-d=e-\-b %( equality _ Int )% 

sort Nat < Int 

V a: Nat 

• a = a — 0 %( Nat 2Int_ embedding) % 

then %def 

preds < , > , < , > : Int x Int; 

even^ odd : Int 

ops — , sign : Int Int; 

abs : Int Nat; 

+ , * , — , mm, max : Int x Int Int; 

" : Int X Nat Int; 

/? , div , quot , 

Int X Int Int; 



rem 
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mod : Int x Int Nat 

%% implied operation attributes : 

ops + : Int X Int Int^ comm^ assoc^ unit 0; %implied 

* : Int X Int Int^ comm^ assoc^ unit 1; %implied 

mm, max : Int x Int Int^ comm^ assoc %implied 

V m, n, r, 5, t: Int; a, 6, c, d: Nat 

%% axioms concerning predicates 

• m<n^{n — m^ Nat) 

•m>n^n<m 

• m<n^m<nA^m = n 

• m>n<An<m 

• even{m) AA even{abs{m)) 

• odd{m) AA ^ even{m) 

• odd{m) AA odd{abs{m)) 

%% xioms concerning operations 

• — {a — b) = b — a %(neg_def_Int)% 

• sign{m) = 0 when m = 0 else 1 when m > 0 else — 1 

% ( sign _ def _ Int ) % 

• abs{m) = — m when m < 0 else m %(abs_def_Int)% 

• {a — b) {c — d) = {a c) — {b d) %(add_def_Int)% 

• (a — 6) * (c — d) = (a * c + 6 * d) — (6 * c + a * d) 

% ( mult _ def _ Int ) % 

• m — n = m -\ n %(sub_def_Int)% 

• min{m^ n) = m when m < n else n %(min_def_Int)% 

• max{m^ n) = n when m < n else m %(max_def_Int)% 

• {— 1) " a = 1 when even{a) else — 1 %(power_negl_Int)% 

• m " a = sign{m) "a * abs{m) "aif^m = — 1 

% (power _ ot hers _ Int ) % 

• def m I? n AA m mod n = 0 %(divide_dom2_Int)% %implied 

• m /I n = rAA^n=OAn^r=m 

%( divide _ alt _ Int )% %implied 

• m p n = sign{m) * sign{n) * {abs{m) /? abs{n)) 

%( divide _ Int )% 

• def m div n AA ^ n = 0 %(div_dom_Int)% %implied 

• m div n = r AA 3 a: Nat •m = n^r-\-aAa< abs{n) 

%(div_Int)% 

%(quot_dom_Int)% %implied 



%(leq_def_Int)% 
%(geq_def_Int)% 
% ( less _ def _ Int ) % 
% ( great er _ def _ Int ) % 
% ( even _ def _ Int ) % 
%(odd_def_Int)% 
%(odd_alt_Int)% 



• def m quot n AA ^ n = 0 
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• {m quot n = r ^ 

3 s: Int •m = n^r-\-sAO>sAs> — abs{n)) if m < 0 

%(quot_neg_Int)% 

• {m quot n = r AA 

3 s: Int •m = n^r-\-sAO<sAs< abs{n)) if m > 0 

% ( quot _ nonneg _ Int ) % 

• def m rem n AA ^ n = 0 %(rem_dom_Int)% %implied 

• {m rem n = s AA 

3 r: Int •m = n^r-\-sAO>sAs> — abs{n)) if m < 0 

%( quot _rem_ Int )% 

• (m rem n = s AA 

3 r: Int •m = n^r-\-sAO<sAs< abs{n)) if m > 0 

% (rem_nonneg_Int ) % 

• def m mod n AA ^ n = 0 %(mod_dom_Int)% %implied 

• m mod n = a AA 3 r: Int •m = n^r-\-aAa< abs{n) 

%(mod_Int)% 



%% important laws 

• {r-\-s)^t = r^t-\-s^t 

• t^{r-\-s) = t^r-\-t^s 
then %implies 

V m, n, r: Int; a, b: Nat 

• def a —1 b ^ a —1 b = a — b 

• m = sign{m) * abs{m) 

• m mod n = m mod abs{n) 

• m = {m div n) * n + m mod n if ^ n 

• abs{m quot n) = abs{m) quot abs{n) 

• abs{m rem n) = abs{m) rem abs{n) 

• m = {m quot n) * n + m rem n if ^ n 

• m " {a b) = m " a ^ m " b 

end 



%(distrl_Int)% %implied 
%(distr2_Int)% %implied 



%(Int_Nat_sub_compat)% 
%( abs _ decomp _ Int )% 
%(mod_abs_Int)% 
= 0 %(div_mod_Int)% 
% ( quot _ abs _ Int ) % 
%(rem_abs_Int)% 
= 0 %( quot _rem_ Int )% 

% (power _Int)% 



spec Rat = %mono 

Int 

then %mono 

generated type Rat ::= / {Int; Pos) 

V A j: Int; p, q: Pos 

• i I p = j /qAAi^q=j^p % (equality _ Rat )% 

sort Int < Rat 

V i: Int 

• i = i I 1 %(Int2Rat_embedding)% 

then %def 

preds < , < , > , > : Rat x Rat 

ops — , abs : Rat Rat; 



, min^ max : Rat x Rat Rat; 
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/ : Rat X Rat Rat; 

" : Rat X Int Rat 

%% implied operation attributes : 

ops + : Rat x Rat Rat^ comm^ assoc^ unit 0; %implied 

* : Rat X Rat Rat^ comm^ assoc^ unit 1 ; %implied 

mm, max : Rat x Rat Rat^ comm^ assoc %implied 

V p, q: Pos; n: Nat; % j: Int; x, z: Rat 

%% axioms concerning predicates 

• (i / p) < (j / q) ^ {i* q) < {j * p) 

• x>y<^y<x 
•x<y^x<yA^x=y 

• x>y<Ay<x 

%% axioms concerning operations 

• - C ! p) = - i ! p 

• ahs{i / p) = abs{i) / p 

• i I p + j I q = {i * q + j * p) / {p * q) 

• X — y = X -\ y 

• {i / p) * {j / q) = {i * j) / {p * q) 

• min{x^ y) = X when x < y else y 

• max{x^ y) = y when x < y else x 

• ^ def X / 0 

• {x /y = zAAx = z^y) if ^y=0 

• X "0 = 1 

• X " suc{n) = X ^ X " n 

• X " p) = 1 / X " p 

%% important laws 

• {xPy)^z = x^zPy^z %(distrl_Rat)% %implied 

• z^{x-\-y) = z^x-\-z^y %(distr2_Rat)% %implied 

then %implies 

V % j: Int; p, q: Pos; x, y: Rat 

• i I p — j /q = {i^q— j^p) / {p ^ q) %(sub_rule_Rat)% 

• def X I y ^ y = 0 %(divide_dom_Rat)% 

• e / p) / (i / q) = e * q) / {p * j) if ^ i = 0 

% ( di vide_ r ule _ Rat ) % 

• X " (i j) = X " i ^ X " j %(power_Rat)% 

end 

spec DeCIMALFrACTION = %mono 
Rat 

then %def 
local 

op tenPower : Nat Nat 



% ( minus _ def _ Rat ) % 
%(abs_def_Rat)% 
%(add_def_Rat)% 
%(sub_def_Rat)% 
% ( mult _ def _ Rat ) % 
%(min_def_Rat)% 
%(max_def_Rat)% 
% ( di vide_ def 1 _ Rat ) % 
% ( di vide_ def 2 _ Rat ) % 
% (power _0_Rat)% 
%(power_suc_Rat)% 
% ( p ower _ neg _ Rat ) % 



%(leq_def_Rat)% 
%(geq_def_Rat)% 
% ( less _ def _ Rat ) % 
% (greater def Rat)% 
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V n, m: Nat 

%% tenPower(n):= min { 10"k | k in N \{0}, 10"k > n }: 

• tenPower{n) = 10 when n < 10 else 10 ^ tenPower{n div 10) 

% (tenPower _def) % 

within 

%% operations to represent a rational as a decimal fraction: 

ops ::: : Nat x Nat Rat; 

E : Rat x Int Rat 

V r: Rat; n, m: Nat; p: Pos; i: Int 

%% represent the decimal fraction n.m as rational: 

• n ::: m = n m I tenPower{m) %(decfract_def)% 

%% introduce an exponent: 

• rEi = r^ 10 " i % (exponent _DecimalFraction)% 

end 
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library Basic/RelationsAndOrders version 1.0 

%authors(M. Roggenbach <csmarkus@swansea.ac.uk>, T. Mossakowski, 
L. Schroder) % 

%date : 18 December 2003 
%{ This library provides 

- specifications of binary relations of different sort, 

- views stating that the numbers specified in the 
Library Basic/Numbers are totally ordered, and 

- a specification of Boolean Algebras. 

Then, the different concepts specified are enriched with additional 
operations and predicates: In case of partial orders, the specification 
Ext Part ialOrder provides the notions of inf, sup; the specification 
ExtTotalOrder adds the functions min and max to total orders; 
ExtBooleanAlgebra defines a complement operation as well as a 
less-or-equal relation for Boolean algebras. 

Einally, the library provides non parametrized variants of these 
enriched specifications. }% 

%display( ~ %LATEX - )% 

%display( <= %LATEX < )% 

%display( >= %LATEX > )% 

%display( cup %LATEX U )% 

%display( cap %LATEX n )% 

%display( comp/ %LATEX 

%prec({__U__} < {__□__})% 



from Basic/Numbers get Nat, Int, Rat 
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spec Relation = 
sort Elem 

pred ~ : Elem x Elem 

end 

spec ReflexiveRelation = 

Relation 

then 

V x: Elem 

• X ^ X %(refi)% 

end 

spec IrreflexiveRelation = 

Relation 

then 

V x: Elem 

• ^ X ^ X %(irrefi)% 

end 

spec SymmetricRelation = 

Relation 

then 

V T, Elem 

• x^yify^x %(sym)% 

end 

spec AsymmetricRelation = 

Relation 

then 

V T, Elem 

• ^x^yify^x %(asym)% 

end 

spec AntisymmetricRelation = 

Relation 



then 

V T, Elem 

• x = yifx^yAy^x %(antisym)% 

end 

spec TransitiveRelation = 

Relation 
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then 

V X, z: Elem 

• x^zifx^yAy^z %(trans)% 

end 

spec SimilarityRelation = 

ReflexiveRelation 

and 

SymmetricRelation 

end 

spec PartialEquivalenceRelation = 

SymmetricRelation 

and 

TransitiveRelation 

end 

spec EquivalenceRelation = 

ReflexiveRelation 

and 

PartialEquivalenceRelation 

end 

spec PreOrder = 

{ ReflexiveRelation 

and 

TransitiveRelation 

with pred ~ ^ < 

end 

spec StrictOrder = 

{ IrreflexiveRelation 

and 

TransitiveRelation 

then %implies 

AsymmetricRelation 

} 

with pred ~ ^ < 

end 

spec PartialOrder = 

PreOrder 

and 

AntisymmetricRelation with pred ~ ^ < 
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end 

spec TotalOrder = 

PartialOrder 

then 

V X, Elem 

• x<y\/y<x % (dichotomy _TotalOrder)% 

end 

spec StrictTotalOrder = 

StrictOrder 

then 

y x^ y: Elem 

• x<y\/y<x\/x = y % (trichotomy _Strict TotalOrder) % 

end 

spec RightUniqueRelation = 

sorts T 

pred R : S x T 

V 5 : S; tl, t2: T 

• s R tl A s R t2 ^ tl = t2 

end 



spec LeetTotalRelation = 

sorts T 

pred R : S x T 

y s: S 

• 3 t: T • s R t 

end 



spec 



BooleanAlgebra = 

sort Elem 

ops 0^ 1 : Elem; 

n : Elem x Elem Elem^ 

U : Elem x Elem Elem^ 

V X, z: Elem 

• X n {x U y) = X 
•xUxny=x 

• xn 0 = 0 

• X U 1 = 1 

• xr\{y\Jz) = xr\yUxr\z 

• X U y n z = {x U y) n {x U z) 

• 3 x': Elem • x U E = 1 A x H x' = 0 



assoe^ eomm^ unit 1 ; 
assoe^ eomm^ unit 0 

% ( absorption _ def 1 ) % 
% ( absorption _ def 2 ) % 
% (zeroAndCap) % 
% (oneAndCup) % 
% (dist r 1 _ BooleanAlgebra) % 
% (dist r 2 _ BooleanAlgebra) % 



then %implies 



%(inverse_ BooleanAlgebra) % 




n 
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end 



ops U 

V x: Elem 

• 3! x': Elem • x U x' = 1 A x H x' = 0 

% ( uniqueComplement _ Boolean Algebra) % 



spec ExtPartialOrder [Partial Order] = %def 

preds < , < , > , > : Elem x Elem 

V X, y: Elem 

• x>yAAy<x %(geq_def_ExtPartialOrder)% 

• x<yAAx<yA^x = y %(less_def_ExtPartialOrder)% 

• x>yAAy<x % (greater _def_ExtPartialOrder)% 

and 



end 



ops m/, sup : Elem x Elem -^7 Elem^ eomm % implied 

V T, z: Elem 

• infix, y) = z ^ 

z < X A z < y A (\/ t: Elem •t<xAt<y^t<z) 

%(inf_def_ExtPartialOrder)% 

• sup{x^ y) = z AA 

X < z A y < z A {\/ t: Elem •x<tAy<t^z<t) 

%(sup_def_ExtPartialOrder)% 



spec ExtTotalOrder [TotalOrder] = %def 
ExtPartialOrder [PartialOrder] 

and 

ops mm, max : Elem x Elem Elem^ eomm^ assoe %implied 

V T, Elem 

• min{x^ y) = X when x < y else y %(min_def_Ext TotalOrder) % 

• max{x^ y) = y when x < y else x %(max_def_Ext TotalOrder) % 

then %implies 

V T, Elem 

• min{x^ y) = inf{x^ y) %(min_inf_relation)% 

• max{x^ y) = sup{x^ y) %(max_sup_relation)% 

end 

spec ExtBooleanAlgebra [BooleanAlgebra] = %def 

preds < , < , > , > : Elem x Elem 

V T, Elem 

• x<yAAxr\y = x %(leq_def_ Ext BooleanAlgebra) % 

• x>yAAy<x %(geq_def_ExtBooleanAlgebra)% 

• x<yAAx<yA^x = y %(less_def_ExtBooleanAlgebra)% 

• x>yAAy<x %(greater_def_ExtBooleanAlgebr)% 



and 
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{ op : Elem Elem 

V X, Elem 

• x~^ = y^xUy=l /\ X n y = 0 

% (compl_def_ExtBooleanAlgebra) % 

then %implies 

V X, Elem 

• {x n y) ~^ = X U y %(de_Morganl)% 

• {x U y) = X n y %(de_Morgan2)% 

• {x = X %(involution_compl_ExtBooleanAlgebra)% 

} 

end 

spec RichPartialOrder = 

ExtPartialOrder [PartialOrder] 

end 

spec RichTotalOrder = 

ExtTotalOrder [TotalOrder] 

end 

spec RichBooleanAlgebra = 

ExtBooleanAlgebra [BooleanAlgebra] 

end 

view TotalOrder_in_Nat : TotalOrder to Nat = 
sort Elem ^ Nat 

end 

view TotalOrder_in_Int : TotalOrder to Int = 
sort Elem ^ Int 

end 

view TotalOrder_in_Rat : TotalOrder to Rat = 
sort Elem ^ Rat 

end 

view PartialOrder_in_ExtBooleanAlgebra [BooleanAlgebra] : 
PartialOrder to ExtBooleanAlgebra [BooleanAlgebra] 



end 
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library Basic/ Algebra_I version 1.0 

%authors : M. Roggenbach, T. Mossakowski, L. Schroder <lschrode@tzi.de> 
%date : 21 May 2003 

%prec({ * } < { ^ })% 

%prec({__+__, 

%left_assoc( + , * , " )% 



from Basic/RelationsAndOrders get 

TotalOrder, ExtTotalOrder, RichTotalOrder, 
PreOrder, EquivalenceRelation 

from Basic/Numbers get Nat, Int, Rat 

spec Monoid = 
sort Elem 
ops e : Elem] 

* : Elem x Elem Elem^ assoe^ unit e 

end 

spec CommutativeMonoid = 

Monoid 

then 

op * : Elem x Elem Elem^ eomm 

end 

spec Group = 

Monoid 



then 
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V x: Elem 

• 3 x': Elem • x' ^ x = e 

end 

spec AbelianGroup = 

Group 

and 

GommutativeMonoid 

end 

spec Ring = 

AbelianGroup with sort Elem^ ops * ^ + , e 0 

and 

Monoid with ops e, * 

then 

V X, z: Elem 

• {x-\-y)^z = x^z-\-y^z %(distrl_Ring)% 

• z^{x^y) = z^x^z^y %(distr2_Ring)% 

end 

view AbelianGroup_in_Ring_add : AbelianGroup to Ring = 
ops e 0^ * ^ + 

end 

spec GommutativeRing = 

Ring with ops 0^ + , e, * 

and 

GommutativeMonoid with ops e, * 

end 

spec IntegralDomain = 

GommutativeRing 

then 

V T, Elem 

• x = 0\/y=0 if x^y=0 

• ^ e = 0 

end 

spec GonstrugtField = 

GommutativeRing 

then 

• ^ e = 0 

sort NonZeroElem = {x: Elem • ^ x = 0} 

and 

Group with sort Elem ^ NonZeroElem^ ops e, * 



% (noZeroDiv) % 
% (zeroNeqOne) % 
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end 

%% an obvious view which helps to write the specification Ext Field: 
view AbelianGroup_in_ConstructField : 

AbelianGroup to GonstructField = 
sort Elem ^ NonZeroElem 

end 

spec Field = 

GonstructField hide sort NonZeroElem 

end 

view IntegralDomain_in_Field : IntegralDomain to Field 

end 

spec ExtMonoid [Monoid] given Nat = %def 
op " : Elem x Nat Elem 

V x: Elem] n: Pos 

• X " 0 = e 

• X " sue{n) = X ^ X " n 

then %implies 

V x: Elem] n, m: Nat 

• e " n = e 

• X " {n m) = X " n ^ X " m 

• X " (n * m) = (t " n) " m 

end 

spec ExtGommutativeMonoid [GommutativeMonoid] 
given Nat = %def 
ExtMonoid [Monoid] 
then %implies 

V T, y: Elem] n: Nat 

• X " n ^ y " n = {x ^ y) " n %(pow_basemult_CMonoid)% 

end 

spec ExtGroup [Group] given Int = %def 
ExtMonoid [Monoid] 

then 

ops " : Elem x Int Elem] 

inv : Elem Elem] 

/ : Elem x Elem Elem 

V T, y: Elem] p: Pos 

• inv{x) * T = e 

• X / y = X ^ inv{y) 

• X " {— p) = inv{x " p) 



%(inv_def_ Group) % 
%(div_def_Group)% 
% (pow_neg_Group) % 



%(pow_0_Monoid)% 

%(pow_suc_Monoid)% 

% (pow_unit _ Monoid) % 
%(pow_add_Monoid)% 
%(pow_mult_Monoid)% 
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then %implies 

V X, z: Elem; n, m: Int 

• X * inv{x) = e 

• x = y if z^x = z^y 

• x = y if x^z = y^z 

• inv{inv{x)) = x 

• inv{e) = e 

• mr;(x * y) = inv{y) * inv{x) 

• e " n = e 

• X " {n m) = X " n ^ X " m 

• X " (n * m) = (x " n) " m 

end 

spec ExtAbelianGroup [AbelianGroup] given Int = %def 
ExtGroup [AbelianGroup] 
then %implies 

V T, y: Elem; n: Int 

• X " n ^ y " n = {x ^ y) " n %(pow_basemult_AbGroup)% 

end 

spec ExtRing [Ring] given Int = %mono 

ExtAbelianGroup [view AbelianGroup_in_Ring_add] 
with ops inv ^ — , / ^ — , " ^ times 

and 

ExtMonoid [Monoid] with op " 

and 

preds islrred^ is Unit : Elem 

sorts NonZero[Elem\ = {x: Elem • ^ t 

RUnit[Elem\ = {x: Elem • isUnit{x)}'^ 

Irred[Elem\ = {x: Elem • islrred{x)} 

V T, Elem 

• isUnit{x) 3 y: Elem •x^y=e/\y^x=e 

% (isU nit _def _ Ring) % 

• islrred(x) 

^ isUnit{x) A (V z: Elem • isUnit{y) V isUnit{z) if x = y ^ z) 

% (isir r ed _ def _ Ring) % 

then %def 

ops e : RUnit[Elem]; 

— : RUnit[Elem] RUnit[Elem]; 

* : RUnit[Elem] x RUnit[Elem] RUnit[Elem] 

end 

view Group_in_ExtRing [Ring] given Int : 

Group to ExtRing [Ring] = 
sort Elem ^ RUnit[Elem] 



%(rightlnv_ Group) % 
% ( left Gancel _ Group ) % 
% (right Gancel _ Group) % 
%(invlnv_ Group) % 
% ( invUnit _ Gr oup ) % 
% (invMult _ Group) % 
% ( pow _ unit _ Group ) % 
%(pow_add_Group)% 
% ( pow _ mult _ Group ) % 
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end 

spec ExtCommutativeRing [CommutativeRing] 

given Int = %mono 

ExtRing [Ring] 

then 

preds hasNoZeroDivisors : (); 

divides : Elem x Elem; 

associated : Elem x Elem 
y y: Elem 

• hasNoZeroDivisors V x, Elem •x = 0\/y=0 if x^y=0 

% (hasNoZeroDivisors_def) % 

• X divides y ^ 3 z: Elem • x ^ z = y %( divides _def)% 

• associated{x^ y) 3 u: RUnit[Elem] • x = u ^ y 

% (associated_def) % 

then %implies 

y x^ y: Elem 

• assoeiated{x^ y) x divides y A y divides x 

end 

view PreOrder_in_ExtCRing [CommutativeRing] given Int : 
PreOrder to ExtCommutativeRing [CommutativeRing] = 
pred < ^ divides 

end 

view AbelianGroup_in_ExtCRing [CommutativeRing] 
given Int : 

AbelianGroup to 

ExtCommutativeRing [CommutativeRing] = 
sort Elem ^ RUnit[Elem] 

end 

view EqRel_in_ExtCRing [CommutativeRing] given Int : 
EquivalengeRelation to 
ExtCommutativeRing [CommutativeRing] = 
pred ~ ^ associated 

end 

spec ExtIntegralDomain [IntegralDomain] 

given Int = %mono 

ExtCommutativeRing [CommutativeRing] 

then 

op * : NonZero[Elem\ x NonZero[Elem\ NonZero[Elem\ 

then %implies 

• hasNoZeroDivisors 
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end 

spec ExtField [Field] given Int = %mono 
ExtRing [Ring] 

then 

closed {ExtAbelianGroup 

[view AbelianGroup_in_ConstrugtField] 
with sort NonZeroElem ^ NonZero[Elem\^ 
ops inv^ / , " 

} 

then 

op / : Elem x Elem -^1 Elem 

V x: Elem; n: NonZero[Elem\ 

• 0 I n = 0 %(div_defl_Field)% 

• ^ def X j 0 %(div_def2_Field)% 

then %implies 

V X, Elem 

• dej X / y ^ y = 0 %(div_dom_Field)% 

end 

spec RighMonoid = 

ExtMonoid [Monoid] 

end 

spec RighGommutativeMonoid = 

ExtGommutativeMonoid [GommutativeMonoid] 

end 

spec RighGroup = 

ExtGroup [Group] 

end 

spec RighAbelianGroup = 

ExtAbelianGroup [AbelianGroup] 

end 

spec RighRing = 

ExtRing [Ring] 

end 

view Group_in_RighRing : Group to RighRing = 
sort Elem ^ RUnit[Elem\ 

end 

spec RighGommutativeRing = 
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ExtCommutativeRing [CommutativeRing] 

end 

view PreOrder_in_RighCRing : 

PreOrder to RighCommutativeRing = 
pred < ^ divides 

end 

view EqRel_in_RighCRing : 

EquivalengeRelation to RighCommutativeRing = 
pred ~ ^ associated 

end 

view AbelianGroup_in_RighCRing : 

AbelianGroup to RighCommutativeRing = 
sort Elem ^ RUnit[Elem] 

end 

spec RighIntegralDomain = 

ExtIntegralDomain [IntegralDomain] 

end 

spec RighField = 

ExtField [Field] 

end 

view CommutativeMonoid_in_Nat_Add : 

CommutativeMonoid to Nat = 

sort Elem ^ Nat^ ops e ^ G * ^ + 

end 

view CommutativeMonoid_in_Nat_Mult : 

CommutativeMonoid to Nat = 

sort Elem ^ Nat^ ops e ^ 4, * ^ * 

end 

view CommutativeMonoid_in_Int_Mult : 

CommutativeMonoid to 
{ Int 

then 

op 1 : Int 

} = 

sort Elem ^ Int^ ops e ^ 4, * ^ * 



end 
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view AbelianGroup_in_Int_Add : 

AbelianGroup to 
{ Int 

then 

op 0 : Int 

} = 

sort Elem ^ Int^ ops * ^ + , e ^ 0 

end 

view IntegralDomain_in_Int : 

IntegralDomain to 
{ Int 

then 

op 1 : Int 

} = 

sort Elem ^ Int^ op e 1 

end 

view Field_in_Rat : 

Field to 
{ Rat 

then 

op 1 : Rat 

} = 

sort Elem ^ Rat^ op e 1 



end 
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Library Basic/SimpleDatatypes 



library Basic/SimpleDatatypes version 1.0 

%authors : T. Mossakowski <till@tzi.de>, M. Roggenbach, L. Schroder 
%date : 18 June 2002 

%{ This library provides unstructured datatypes like Booleans 
and characters. 

The Booleans are shown to be a Boolean algebra and then 
enriched with the usual Boolean algebra operations. 

The characters are defined to be the subset 0..255 
of the natural numbers, and then constants for different 
representations (ASCII, decimal, octal, hexadecimal) 
are introduced. }% 

%prec({ Or } < { And })% 

from Basic/Relations AndOrders get 

BooleanAlgebra, ExtBooleanAlgebra 

from Basig/Numbers get Nat 

spec Boolean = %mono 
free type 

Boolean ::= True \ False 

%%capital True and False, since true and false are predefined 

ops Not : Boolean Boolean'^ 

And , Or : Boolean x Boolean Boolean 

V T, Boolean 

• Not False = True %( Not _ False) % 

• Not True = False %(Not_True)% 

• False And False = False %(And_defl)% 

• False And True = False %(And_def2)% 
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• True And False = False 

• True And True = True 

• X Or y = Not {Not x And Not y) 

end 

view BooleanAlgebra_in_Boolean : 

BooleanAlgebra to Boolean = 
sort Elem ^ Boolean^ 

ops 0 False^ 1 ^ True^ □ ^ And , 

U ^ Or 

end 

%{ Get derived operations for Boolean Algebras }% 
spec RiGHBoOLEAN = %mono 

ExtBooleanAlgebra [view BooleanAlgebra_in_Boolean] 

with pred < , op 

end 

spec Char = %mono 
Nat 

then %mono 

%% characters are generated from natural numbers 0..255 



type Char ::= ehr{ord:Nat)l 
V n: Nat; e: Char 


• def ehr{n) n < 255 


%(chr dom)% 


• 

o 

AL- 

II 


% (chr_ord_inverse) % 


%% definition of individual characters by 


decimal codes: 


ops ^\000^: Char = ehr{0); 


%(slash_000)% 


II 


%(slash_001)% 


^\002^: Char = ehr{2); 


%(slash_002)% 


^\003^: Char = ehr{3); 


%(slash_003)% 


II 


%(slash_004)% 


’1^55’: Char = chr{255) 


% (slash 255)% 


%% definition of the printable characters 
%% This relies on the character names 


0 

P 

II 


% (printable 32)% 


7’: Char = ’\033’; 


% (printable 33)% 


9 

II 


%(printable_34)% 


Char = ’\035’; 


% (printable 35)% 


II 


%(printable_255)% 


preds isLetter{e: Char) 



(ord(A^) < ord{e) A ord{e) < ord{’Z’)) V 
(ord{A^) < ord{e) A ord{e) < ord{^z^)); 



% ( And_def3) % 
%(And_def4)% 
%(Or_def)% 
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%(isLetter def)% 


isDigit{c: Char) ord(’O’) < ord{c) A 


ord{c) < ord{^9’); 




%(isDigit def)% 


is Printable {c: Char) 




{ord{^ ’) < ord{c) A ord{c) < ord{^'^’)) V 


{ord{^ ^) < ord{c) A ord{c) < ord{^y^)) 


% (isPrintable_def) % 


%% definition of characters by octal codes, i.e. ’\o 


PPP’. 


%% where p in {0,1, ...,7} : 




ops ’\o000’: Char = ’\000’; 


%(slash_o000)% 


’\o00P: Char = ’\00P; 


%(slash o001)% 


’\o002’: Char = ’\002’; 


%(slash_o002Ao 


o 

II 


%(slash_o003Ao 


o 

II 


%(slash o004)% 


’\o377’: Char = ’\255’ 


%(slash_o377)% 


%% definition of characters by hexadecimal codes, 


i.e. Vhh’, 


%% where h in {0,1,..., F} : 




ops ’\x00’: Char = ’\000’; 


% (slash_x00) % 


’\x01’: Char = ’\001’\ 


% (slash x01)% 


’\x02’: Char = ’\002’; 


% (slash_x02) % 


’\x03’: Char = ’\003’; 


% (slash x03)% 


’\x04’: Char = ’\004’; 


% (slash x04)% 


’\xFF’: Char = ’\255’ 


%(slash_xFF)% 


%% special characters: 




ops NUL: Char = ’\000’; 


%(NUL_def)% 


SOH: Char = ’\001’; 


%boH_def)% 


SYX: Char = ’\002’\ 


%bYX_def)% 


ETX: Char = ’\003’; 


%(ETX_def)% 


k 

II 

O 


%(EOT_defAo 


ENQ: Char = ’\005’; 


%(ENQ_def)% 


ACK: Char = ’\006’; 


%(ACK_defAo 


BEL: Char = ’\007’; 


%(BEL_defAo 


BS: Char = ’\008’; 


%(BS_def)% 


HT: Char = ’\009’; 


%(HT_defAo 


II 


%(LE_defAo 


VT: Char = 


%(VT_def)% 


FF: Char = ’\012’; 


%(FF_def)% 


II 


%(CR_defAo 


SO: Char = ’\014’; 


%(SO_def)% 


SI: Char = ’\015’; 


%(SI_def)% 


DLE: Char = ’\016’; 


%(DLE_def)% 


DCl: Char = ’\017’; 


%(DCl_def)% 


DC2: Char = ’\018’; 


%pC2_def)% 


DCS: Char = ’\019’; 


%pC3_def)% 
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II 


’\020’; 


%(DC4_def)% 


NAK: Char = 


-- ’\021’] 


%(NAK_def)% 


SYN: Char = 


’\022’; 


%(SYN_def)% 


ETB: Char = 


’\023’; 


%(ETB_def)% 


CAN: Char = 


■- ’\024’; 


%(CAN_def)% 


EM: Char = 


’\025’; 


%(EM_def)% 


SUB: Char = 


’\026’\ 


%(SUB_def)% 


ESC: Char = 


’\027’; 


%(ESC_def)% 


FS: Char = ’ 


\028’; 


%(FS_def)% 


GS: Char = ’ 


\029’; 


%(GS_def)% 


RS: Char = ’ 


\030’; 


%(RS_def)% 


US: Char = ’ 


\ 031 


%(US_def)% 


SB: Char = ’ 


\032’; 


%(SP_def)% 


DEL: Char = 


’\127’ 


%(DEL_def)% 



%% alternative names for special characters: 

ops NL: Char = LF; %(NL_def)% 

NP: Char = FF %(NP_def)% 

%% character constants: 



(nb Char 


= NL; 


% (slash n)% 


\C: Char 


= HT; 


%(slash_t)% 


\v^: Char 


= VT; 


% (slash v)% 


\b’: Char 


= BS; 


% (slash h)% 


(rb Char 


= CR; 


%(slash_r)% 


1/4 Char 


= FF; 


% (slash f)% 


lab Char 


= BEL; 


% (slash a)% 


\?’: Char 


= ’f’ 


%(slash_quest)% 



end 
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Library Basic / StructuredDatatypes 



library Basic /StructuredDatatypes version 1.0 

%authors(M. Roggenbach <csmarkus@swansea.ac.uk>, T. Mossakowski, 
L. Schroder) % 

%date : 18 December 2003 

%left_assoc( + , — , ++ )% 

%left_assoc( U , n )% 

%right assoc( :: )% 

%list [ Jj, [], 

%prec({__++__} < 

%string empty String, : @ : 

%display(no^/im^ %LATEX A)% 

%display( eps %LATEX e )% 

%% note: \epsilon looks different from \in, 

%% which is used as LaTeX display syntax 
%% for the CASE membership predicate 

%display( isSubsetOf %LATEX C )% 

%display( intersection %LATEX n )% 

%display( union %LATEX U )% 

%display(# %LATEX ft )% 



from Basic/Numbers get Nat, Int 

from Basic/RelationsAndOrders get 
PartialOrder, BooleanAlgebra 

from Basic/ Algebra_I get Monoid, CommutativeMonoid 

from Basic/SimpleDatatypes get Char 
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spec Maybe [sort S] = %mono 

free type Maybe[S] ::= ± | sort S 

end 

spec Pair [sort S] [sort T] = %mono 

free type Pair[S^T] ::= pair {first: S; second: T) 

end 

spec GenerateSet [sort Elem] = %mono 

generated type Set[Elem] ::= {} | + {Set[Elem\; Elem) 

pred e : Elem x Set[Elem] 

y y: Elem] M, N: Set[Elem\ 

• ^ X e {} %(elemOf_ empty _ Set )% 

• X e {M -\-y)^x = y\/xeM %(elemOf_NonEmpty_Set)% 

• M = N ^ y x: Elem •xeM^xeN %( equality _Set)% 

end 

spec Set [sort Elem] given Nat = %mono 
GenerateSet [sort Elem] 
then %def 

preds isNonEmpty : Set[Elem]; 

C : Set[Elem] x Set[Elem] 

ops { } : Elem Set[Elem]; 

: Set[Elem] Nat; 

+ : Elem x Set[Elem] Set[Elem]; 

— : Set[Elem] x Elem Set[Elem]; 

n , U , - , symDiff : 

Set[Elem] x Set[Elem] Set[Elem] 

%% implied operation attributes 

ops U : Set[Elem] x Set[Elem] Set[Elem] 

assoe^ eomm^ idem^ unit {}; 

n : Set[Elem] x Set[Elem] Set[Elem] 

assoe^ eomm^ idem 
y x^ y: Elem; O: Set[Elem] 

%% axioms concerning predicates 

• isNonEmpty{M) ^ M = {} % (isNonEmpty _def)% 

• M C N 4=^ y x: Elem •xeM^xeN %(isSubsetOf_def)% 

%% axioms concerning operations 

• = + t %(singletonSet_def)% 

• tJ {} = 0 % (number Of _empty Set )% 

• {M + x) = M when x e M else M + 4 

% (number Of _NonEmpty Set )% 

• x-\-M = M-\-x %(addElem_def_Set)% 



%implied 

%implied 
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• {} — y = {} %(remElem_ Empty Set )% 

• (M -^x) — y = M — y when x = y else {M — y) x 

% ( r emElem _ N onEmpty S et ) % 

• Mn{} = {} %(intersection_Emptyset)% 

• M n {N x) = {M n N) + X when x e M else M D N 

% (intersect ion_ N onEmpty Set ) % 

• M U {} = M %(union_ Empty Set )% 

• Mu {N-\-x) = MUN when x e M else {M U N) x 

%(union_NonEmptySet)% 

• M — {} = M %(dif_Emptyset)% 

• M-{N^x) = M- N- x %(dif_Emptyset)% 

• M symDiff N = {M - N) U {N - M) %(symDiff_def)% 



%% important laws 

• (M U N) 0 0 = {M n O) U {N n O) %(distrl_Set)% %implied 

• O 0 {M U N) = {O 0 M) U {O 0 N) %(distr2_Set)% %implied 

then %implies 

V X, Elem; M, N: Set[Elem] 

• w {M U N) = {W M ^ w N) -7 W {M 0 N) %(set_counting)% 

• M < (M U N) %(union_counting)% 

• MU (M U N) %(union_isSubsetOf)% 

• (M n N) C M %(intersection_isSubsetOf)% 

end 



view PartialOrder_in_Set [sort Elem] given Nat : 
PartialOrder to Set [sort Elem] = 
sort Elem ^ Set[Elem]^ pred < ^ C__ 

end 



spec PowerSet [ Set [sort Elem] 
then 

op X : Set[Elem]] 

given Nat = %mono 

sorts PowerSet[X] = {Y: Set[Elem] •YU X}; 

Elem[X] = {x: Elem • x e X} 

preds e : Elem[X] x PowerSet[X]; 

C : PowerSet[X] x PowerSet[X]; 

isN onEmpty : PowerSet[X] 
ops {}, X : PowerSet[X]] 

: Powers et[X] Nat; 

+ : Elem[X] x Power Set[X] Power Set[X]; 

— : Powers et[X] x E^/em[X] ^ PowerSet[X]; 

n , U , - , symDiff : 

PowerSet[X] x PowerSet[X] PowerSet[X] 
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end 



%% implied operation attributes 

ops U : PowerSet[X] x PowerSet[X] 

assoc^ comm^ idem^ unit {}; 

n : PowerSet[X] x PowerSet[X] 

assoc^ comm^ idem 



Powers et[X]^ 

%implied 

Power Set[X]^ 

%implied 



%% important laws 

y M, N, O: Powers et[X] 

• {M u N) n O = {M n O) u {N n O) 

% (distr 1_ Power Set )% %implied 

• O n {M u N) = {O n M) u {O n N) 

% (distr 2_ Power Set )% %implied 



view BooleanAlgebra_in_PowerSet [ Set [sort Elem] 

then 

op X : Set[Elem]] 

given Nat : 

BooleanAlgebra to 
PowerSet [ Set [sort Elem] 
then 

op X : Set[Elem]] = 
sort Elem ^ PowerSet[X]^ 

ops 0 I — ^ ^ ^ A”, n I — ^ Pi , u I — ^ u 

end 



spec GenerateList [sort Elem] = %mono 

free type List[Elem] ::= [] | :: {first:? Elem; rest:? List[Elem]) 

end 



spec List [sort Elem] given Nat = %mono 
GenerateList [sort Elem] 
then %def 

preds isEmpty : List[Elem]; 

e : Elem x List[Elem] 

ops + : List[Elem] x Elem List[Elem]; 

firsf last : List[Elem] -^? Elem; 
fronf rest : List[Elem] -^? List[Elem]; 

: List[Elem] Nat; 

++ : List[Elem] x List[Elem] List[Elem]; 

reverse : List[Elem] List[Elem]; 

! : List[Elem] x Nat -^? Elem; 

take^ drop : Nat x List[Elem] -^? List[Elem]; 
freq : List[Elem] x Elem Nat 
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V X, y: Elem; n: Nat; p: Pos; L, K: List[Elem] 



%% axioms concerning predicates 

• isEmpty(L) L = [] 

• ^ X e [] 

• X e {x :: L) 

• {x e {y :: L) X e L) if ^ x = y 



% (isEmpty _def) % 
% (List _elemOf_nil) % 
%(List_elemOf_NeListl)% 
%(List_elemOf_NeList2)% 



%% axioms concerning operations 
L -\- X = L ] 

def first (L) ^ isEmpty {L) 

def first{\ ]) 

def last(L) ^ isEmpty (L) 

- def last{[ ]) 



%(append_def)% 
% (first _dom)% %implied 
% (first _partial_nil)% %implied 
%(last_dom)% %implied 
%(last_nil)% 



last{x :: L) = x when isEmpty {L) else last{L) %(last_NeList)% 



def front (L) ^ isEmpty {L) 

def front {[ ]) 
front{L x) = L 
def rest{L) ^ isEmpty {L) 
^ def rest{[ ]) 

n\ = o 

U \x :: L) = SMc(U L) 

K = K 

X ii L H — h K — X (r H — h 

reverse ([]) = [] 
reverse{x :: L) = reverse(L) 
def L\n<=^\\L>n 
^ def []\ n 
{x :: L) \ 0 = X 
{x :: L) ! sue{p) = L \ p 
def take{n^ L) L > n 



% (front _dom)% %implied 
% (front _nil)% 
% ( front _ NeList ) % 
%(rest_dom)% %implied 
%(rest_nil)% %implied 
% (number Of_ nil _ List ) % 
%(numberOf_NeList_List)% 
%(concat_nil_List)% 
%(concat_NeList_List)% 
% (reverse_nil) % 
% (reverse _ N eList ) % 
%(index_dom)% %implied 
%(index_nil)% 
%(index_0)% 
%(index_suc)% 
%(take_dom)% %implied 



take{n^ L) = K 3 S: List[Elem\ • K ++ S = L/\^K = n 

%(take_def)% 

def drop{n^ L) L > n %(drop_dom)% %implied 

drop{n^ L) = K 3 S: List[Elem] • S ++ K = LA\\S = n 

%(drop_def)% 

freq{[ ], x) = 0 %(freq_nil)% 

freq{x :: L, y) = sue{freq{L^ y)) when x = y else freq{L^ y) 

% (freq_ N eList ) % 



then %implies 

free type List[Elem\ ::= [] | + {front:! List[Elem\; last:! Elem) 

V L: List[Elem] 

• first{L) :: rest{L) = L if ^ isEmpty{L) % (first _rest)% 

• front{L) + last{L) = L if ^ isEmpty(L) %( front _ last )% 



end 
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view Monoid_in_List [sort Elem] given Nat : 

Monoid to List [sort Elem] = 

sort Elem ^ List[Elem]^ ops e ^ [], * ^ ++ 

end 



spec String = %mono 

List [Char fit sort Elem ^ Char] 
with sort List[Char] ^ String^ 

ops [] ^ empty String^ :: ^ : @ : 

end 



spec GenerateMap [sort S] [sort T] = %mono 

generated type Map[S^T] ::= empty \ [ / ]{Map[S^T]] T; S) 

op lookup : S X Map[S^T] -^1 T 
V M, N: Map[S,T]‘ s, si, s2: S; tl, t2: T 

• ^ def lookup {s, empty) %(lookup_empty_Map)% 

• lookup{s, M [ tl / si ]) = tl when s = si else lookup{s, M) 

% ( lookup _nonEmpty_ Map) % 
^M = N^Ws:S^ lookup{s, M) = lookup{s, N) 

% (equality _ Map) % 



end 



spec Map [sort S] [sort T] given Nat = %mono 
GenerateMap [sort S] [sort T] 

and 

Set [sort S] 

and 

Set [sort T] 
then %def 

free type Entry[S,T] ::= [ / ]{target:T; soureeiS) 

preds isEmpty : Map[S,T]; 

e : Entry[S,T] x Map[S,T]; 

:: - > : Map[S,T] x Set[S] x Set[T] 

ops + , — : Map[S,T] x Entry[S,T] Map[S,T]; 

- : Map[S,T] x S ^ Map[S,T]; 

- : Map[S,T] x T ^ Map[S,T]; 

dom : Map[S,T] Set[S]; 
range : Map[S,T] Set[T\, 

U : Map[S,T] x Map[S,T] Map[S,T] 

V M, N, O: Map[S,T]; s, si, s2: S; t, tl, t2: T; e: Entry[S,T]; 

X: Set[S]; Y: Set[T] 

%% axioms concerning predicates 

• isEmpty {M) ^ M = empty % (isEmpty _ def _ Map) % 
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• [ t / s ] e M ^ lookup{s^ M) = t %(elemOf_def_Map)% 

• M :: X — > ¥4^ dom{M) = X A range{M) C Y 

% ( ar r ow _ del _ M ap ) % 

%% axioms concerning operations 

• M [ t / s ] = M [ t / s ] %(overwrite2_def_Map)% 

• empty — [ t / s \ = empty %( minus _ empty _ Map) % 

• M[t/s\ — [tl / si ] = 

M — s when [ t / s ] = [ tl / si ] else {M — [ tl / si ]) -\- [ t / s ] 

% ( minus _ nonEmpty _ M ap ) % 

• empty — s = empty %(minusSource_empty_Map)% 

• (M X e) — s = 

M — s when 3t:T9e = [t/s] else {M — s) e 

%(minusSource_nonEmpty_Map)% 

• empty — t = empty %(minusTarget_ empty _ Map )% 

• (M X e) — t = 

M — souree{e) — t when target {e) = t else {M — t) e 

% ( minusTar get _ nonEmpty _ Map) % 

• s e dom{M) AA def lookup{s^ M) %(dom_def_Map)% 

• t e range{M) AA ^ s: S • lookup{s^ M) = t %(range_def_Map)% 

• M U N = O AA V e: Entry[S^ T]%eeO<AeeM\/eeN 

%(union_def_Map)% 



end 



%% important laws 

• def lookup{s^ M) AA^t:T%[t/s\eM 

%(lookup_dom)% %implied 

• (M [tl /s\)[t2/s\ = M[t2/s\ 

%(overwrite_Map)% %implied 

• (M [tl / si ])[ t2 / s2 ] = {M [ t2 / s2 ]) [ tl / si] if ^sl=s2 

%(comm_Map)% %implied 



spec Finite [sort Elem] = 

{ Nat 

then 

op / : Nat -^7 Elem 

• V t: Elem • 3 n: Nat • /(n) = x %(f_surjective)% 

• 3 n: Nat • V m: Nat • def f{m) ^ m < n %(f_bounded)% 

} 

reveal Elem 

end 



spec TotalMap [Finite [sort S]] [sort T] = %mono 
{ Map [sort S] [sort T] 
then 
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sort TotalMap[S^T] = {M: Map[S^T] 

• V x: S • def lookup{x^ M)} 

ops [ / ] : 

TotalMap[S^T] x T x S ^ TotalMap[S^T]; 
lookup : S X TotalMap[S^T] T; 

“h ' 

TotalMap[S^T] x Entry[S^T] TotalMap[S^T]; 
range : TotalMap[S^T] Set[T]; 

U : 

TotalMap[S^T] x TotalMap[S^T] -^7 TotalMap[S^T] 
pred e : Entry[S^T] x TotalMap[S^T] 

} 

hide Map[S,T] 

end 

spec GenerateBag [sort Elem] given Nat = %mono 

generated type Bag[Elem] ::= {} | + {Bag[Elem\; Elem) 

op freq : Bag[Elem] x Elem Nat 
y y: Elem] M, N: Bag[Elem] 

• fregii}, y) = 0 %(freq_empty_Bag)% 

• freq{M -\- x, y) = suc{freq{M, y)) when x = y else freq{M, y) 

% ( freq_ nonEmpty _ B ag) % 

• M = N ^ y x: Elem • freq{M^ x) = freq{N^ x) % (equality _ Bag) % 

end 

spec Bag [sort Elem] given Nat = %mono 
GenerateBag [sort Elem] 
then %def 

preds isEmpty : Bag[Elem]; 

e : Elem x Bag[Elem]; 

C : Bag[Elem] x Bag[Elem] 

ops + : Elem x Bag[Elem] Bag[Elem]; 

— : Bag[Elem] x Elem Bag[Elem]; 

- , U , n : 

Bag[Elem] x Bag[Elem] Bag[Elem]; 

{ }(t: Elem): Bag[Elem] = {} + t %(singleton_def_Bag)% 

%% implied operation attributes 

ops U : Bag[Elem] x Bag[Elem] Bag[Elem]^ 

assoe^ eomm^ unit {}; %implied 

n : Bag[Elem] x Bag[Elem] Bag[Elem]^ 

assoe^ eomm^ idem %implied 

V n, m: Nat] y: Elem] N^ O: Bag[Elem] 

%% axioms concerning predicates 

• isEmpty {M) M = {} %( isEmpty _ def _Bag)% 
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• X e M 4=^ freq{M^ x) > 0 %(elemOf_def_Bag)% 

• M C N ^ W x: Elem • freq{M^ x) < freq{N^ x) 

%(isSubsetOf_def_Bag)% 



end 



%% axioms concerning operations 

• x + M = M + x %(addElem_def_Bag)% 

• M - X = N 

V y: Elem 

• {freq{N, y) = freq{M, x) -\ 1 if x = y) A 
(freq{N^ y) = freq{M^ y) if ^ x = y) %(removeElem_def_Bag)% 

• M - N = O AA 

V x: Elem • freq{0^ x) = freq{M^ x) — ! freq{N^ x) 

% (difference_ def _ Bag) % 

• M U N = O AA V x: Elem • freq{0^ x) = freq{M^ x) + freq{N^ x) 

%(union_def_Bag)% 

• M N = O AA 

V x: Elem • freq{0^ x) = min{freq{M^ x), freq{N^ x)) 

%(intersection_def_Bag)% 



view CommutativeMonoid_in_Bag [sort Elem] given Nat : 
CommutativeMonoid to Bag [sort Elem] = 
sort Elem ^ Bag[Elem]^ ops e ^ {}, * ^ U 

end 



view PartialOrder_in_Bag [sort Elem] given Nat : 
PartialOrder to Bag [sort Elem] = 
sort Elem ^ Bag[Elem]^ pred < ^ C_ 

end 



spec Array [ops min^ max : Int 

• min < max %(Cond_nonEmptyIndex)%] 

[sort Elem] 
given Int = %mono 

sort Index = {i: Int • min < i A i < max} 

then %mono 

{ Map [sort Index] [sort Elem] 

with sort Map[Index^Elem] ^ Array[Elem], op empty ^ init 

then 

ops ! := : 

Array[Elem] x Index x Elem Array[Elem]] 

! : Array[Elem] x Index -^1 Elem 

V A: Array [Elem]; i: Index; e: Elem 

• A!i:=e = A[e / i ] %( assignment _ def) % 

• A \ i = lookup {p A) %(lookup_def)% 
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} 

reveal sort Array [Elem]^ ops init^ ! , ! := 

then %implies 

V A: Array[Elem\; j: Index] e, /: Elem 

• ^ def init ! i %( lookup _ domain l_Arr ay )% 

• def {A\ i := e) \ i %(lookup_domain2_ Array )% 

• (A \ i := e) \ j = e if i = j %( lookup _ assignment l_Arr ay )% 

• {A \ i := e) \ j = A \ j if ^ i = j 

% ( lookup _ assignment 2_Array)% 



end 



spec GenerateBinTree [sort Elem] = %mono 
free type 

BinTree[Elem\ ::= nil 

I binTree{entry:l Elem; left:lBinTree[Elem\; 
right : ? Bin Tree [Elem ] ) 

end 



spec BinTree [sort Elem] given Nat, Set [sort Elem] = %mono 
GenerateBinTree [sort Elem] 

and 

Set [sort Elem] 
then %def 

preds isEmpty^ isLeaf : BinTree[Elem]; 
isCompoundTree : BinTree[Elem]; 

e : Elem x BinTree[Elem] 

ops height : BinTree[Elem] Nat; 

leaves : BinTree[Elem] Set[Elem] 

y y: Elem; T, T4, T2: BinTree[Elem] 

%% axioms concerning predicates 

• isEmpty(T) T = nil %(isEmpty_def_ BinTree) % 

• ^ isLeaf{nil) %(isLeaf_nil_ BinTree) % 

• isLeaf {binTree{x^ Tl^ T2)) T1 = nil A T2 = nil 

% (isLeaf_binTree) % 

• ^ isCompoundTree {nil) %(isCompoundTree_nil_ BinTree) % 

• isCompoundTree{binTree{x^ T4, T2)) AA 
^ isLeaf {binTree{x^ T4, T2)) 

% (isCompoundTree_binTree) % 

• ^ X e nil %(eps_nil_BinTree)% 

• X e binTree{y^ T4, T2) <Ax = y\/xeTl W x e T1 

%(eps_binTree)% 



%% axioms concerning operations 
• height {nil) = 0 



% (height _ nil _ BinTree) % 
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end 



• height {hinTree{x^ Tl^ T2)) = max {height (Tl)^ height {T 2)) + 1 

% (height _BinTree) % 

• leaves{nil) = {} %(leaves_nil_BinTree)% 

• leaves {binTree{x^ Tl^ T2)) = 

{ X } when isLeaf {binTree{x^ Tl^ T2)) 
else leaves {Tl) U leaves {T2) 

% (leaves_ BinTree) % 



spec GenerateBinTree 2 [sort Elem] = %mono 
free types NonEmptyBinTree2[Elem] ::= 
leaf ( entry : ? Elem ) 

I bin Tree ( left : ? NonEmptyBin Tree2 [Elem ] ; 

right:! NonEmptyBinTree2[Elem\) ; 

BinTree 2[Elem] ::= nil \ sort NonEmptyBinTree2[Elem] 



end 



spec BinTree 2 [sort Elem] 

given Nat, Set [sort Elem] = %mono 
GenerateBinTree 2 [sort Elem] 

and 

Set [sort Elem] 
then %def 

preds isEmpty^ isLeaf : BinTree2[Elem]; 
isCompoundTree : BinTree 2[Elem]'^ 

e : Elem x BinTree 2[Elem] 

ops height : BinTree 2[Elem] Nat; 

leaves : BinTree 2[Elem] Set[Elem] 

y x^ y: Elem; T: BinTree 2 [Elem]; Nl^ N2: NonEmptyBinTree2[Elem] 



%% axioms concerning predicates 

• isEmpty(T) T = nil 

• isLeaf {leaf (x)) 

• ^ isLeaf {binTree{N N2)) 

• ^ is Leaf {nil) 

• ^ isCompoundTree{leaf {x)) 



%(isEmpty_def_BinTrec2)% 
% (isLeaf_leaf_BinTrec2) % 
% (isLeaf_binTree_BinTrec2) % 
%(isLeaf_nil_BinTrec2)% 



% (isComponndTree_leaf_BinTrec2) % 

• isCompoundTree{binTree{Nl^ N2)) 

% (isComponndTree_binTree_BinTrec2) % 

• ^ isCompoundTree {nil) %(isComponndTree_nil_BinTrec2)% 

• X e leaf{y) ^ x = y %(eps_leaf_BinTrec2)% 

• X e binTree{NC N2) ^ x e N1 V t e N2 



% (eps_binTree_BinTrec2) % 
% (eps_nil_BinTrec2) % 



• ^ X e nil 
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%% axioms concerning operations 

• height {leaf (x)) = 1 %( height _ leaf _binTree2)% 

• height {binTree{Nl^ N2)) = max {height {Nl)^ height{N2)) + 1 

% (height _binTree_ BinTree2) % 

• height {nil) = 0 % (height _nil_BinTree2)% 

• leaves {leaf {x)) = { x } %( leaves _ leaf _BinTree2)% 

• leaves {binTree{Nl^ N2)) = leaves{Nl) U leaves{N2) 

%(leaves_binTree_BinTree2)% 

• leaves{nil) = {} %( leaves _ nil _BinTree2)% 

end 



spec GenerateNTree [sort Elem] = %mono 
free types 

List[NTree[Elem]] ::= [] 

I :: {first:? NTree[Elem]; 

rest : ? List [NTree [Elem] ] ) 

NTree[Elem] ::= nil 

I nTree {entry:? Elem; 

branehes : ? List [NTree [Elem] ] ) 



end 



spec NTree [sort Elem] given Nat, Set [sort Elem] = %mono 

GenerateNTree [sort Elem] 

and 

Set [sort Elem] 

and 

List [sort NTree[Elem]] 

then %def 

preds isEmpty^ isLeaf : NTree[Elem]; 
isCompoundTree : NTree[Elem]; 

e : Elem x NTree[Elem]; 

is branehing : NTree[Elem] x Nat 

ops height : NTree[Elem] Nat; 

maxH eight : List[NTree[Elem^ Nat; 
leaves : NTree[Elem] Set[Elem]; 
allLeaves : List[NTree[Elem]] Set[Elem] 

V T, Elem; T: NTree[Elem]; L: List[NTree[Elem\\; n: Nat 

%% axioms concerning predicates 

• isEmpty{T) T = nil %(isEmpty_def_NTree)% 

• ^ isLeaf {nil) % (isLeaf_ nil _N Tree )% 

• isLeaf {nTree{x^ L)) V T: NTree[Elem] • T e L ^ T = nil 

% (isLeaf_nTree) % 

• ^ isCompoundTree {nil) %(isCompoundTree_nil_ NTree) % 

• isCompoundTree{nTree{x^ L)) ^ ^ isLeaf {nTree{x^ L)) 
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% (isCompoundTree_nTree) % 

• ^ X e nil %(eps_nil_NTree)% 

• X e nTree{y^ L) y V (3 T: NTree[Elem] •TeLAxeT) 

%(eps_nTree)% 

• nil is n branching %(isKbranching_nil_NTree)% 

• nTree{x^ L) is n branching AA 

L=U V 

(fl L = n A (V T: NTree[Elem] •TeL^T is n branching)) 

%(isKbranching_nTree_NTree)% 



end 



%% axioms concerning operations 

• height {nil) = 0 %( height _ nil _NTree)% 

• height {nTree{x^ L)) = maxHeight{L) + 1 % (height _nTree)% 

• maxHeight{[ ]) = 0 %(maxHeight_nil)% 

• maxHeight{T :: L) = max {maxH eight {L)^ height {T)) 

% (maxHeight _nonEmpty List ) % 

• leaves{nil) = {} %( leaves _ nil _NTree)% 

• leaves {nTree{x^ L)) = 

{ X } when isLeaf {nTree{x^ L)) else allLeaves{L) %( leaves _nTree)% 

• allLeaves{[ ]) = {} %(allLeaves_nil)% 

• allLeaves{T :: L) = allLeaves{L) U leaves {T) 

% ( allLeaves _ nonEmpty List ) % 



spec GenerateNTree2 [sort Elem] = %mono 
free types 

NonEmpty List[NonEmptyNTree2 [E^/em]] ::= 

: : {first : NonEmptyNTree2 [Elem ] ; 

rest : List [NonEmptyNTree2 [Elem] ] ) ; 
List[NonEmptyNTree2[Elem]] ::= 

11 

I sort NonEmpty List[NonEmptyNTree2[Elem]] ; 

NonEmpty NTree2 [Elem] : : = 
leaf ( entry : ? Elem) 

I nTree {branches:? NonEmpty List[NonEmptyNTree2 [Elem]]) ; 
NTree2[Elem] ::= nil \ sort NonEmptyNTree2[Elem] 

end 



spec NTree2 [sort Elem] given Nat, Set [sort Elem] = %mono 
GenerateNTree2 [sort Elem] 

and 

Set [sort Elem] 

and 

List [sort NonEmptyNTree2[Elem]] 

then %def 
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preds isEmpty^ isLeaf : NTree2[Elem\; 
isCompoundTree : NTree2[Elem]; 

e : Elem x NTree2[Elem]; 

is branching : NTree2[Elem] x Nat 

ops branches : 

NTree2[Elem\ NonEmptyList[NonEmptyNTree2[Elem]]; 
h : List[NonEmptyNTree2[Elem\] x Nat Nat; 

%% helps defining height 
height : NTree2[Elem\ Nat; 

I : List[NonEmptyNTree2[Elem\] Set[Elem\; 

%% helps defining leaves 
leaves : NTree2[Elem\ Set[Elem] 
y y: Elem; n: Nat; T: NTree2[Elem\; 

NT : NonEmptyNTree2 [Elem] ; 

L: NonEmptyList [NonEmptyNTree2 [^/em]] ; 

K: List[NonEmptyNTree2[Elem]] 



%% axioms concerning predicates 

• isEmpty{T) T = nil 

• is Leaf {leaf (x)) 

• ^ isLeaf {nTree{L)) 

• ^ isLeaf {nil) 

• ^ isCompoundTree{leaf {x)) 

• isCompoundTree{nTree{L)) 



%(isEmpty_def_NTrec2)% 

%(isLeaf_leaf_NTrec2)% 

%(isLeaf_nTree_NTrec2)% 

%(isLeaf_nil_NTree2)% 

%(isCompoundTree_leaf_NTree2)% 



% (isCompoundTree_nTree_NTree2) % 

• ^ isCompoundTree {nil) %(isCompoundTree_nil_NTree2)% 

• X e leaf{y) x = y %(eps_leaf_NTrec2)% 

• X e nTree{L) 3 T: NonEmptyNTree2[Elem] •TeLAxeT 

% (eps_nTree_NTrec2) % 

• ^ X e nil %(eps_nil_NTree2)% 

• leaf{x) is n branching %(isKbranching_leaf_NTree2)% 

• nTree{L) is n branching AA 
\\ L = n A 

(V T: NonEmptyNTree2[Elem] •TeL^T is n branching) 

% (isKbranching_nTree_NTree2) % 

• nil is n branching %(isKbranching_nil_NTree2)% 



%% axioms concerning operations 

• ^ def branches {nil) %(branches_nil_nTree2)% 

• /i([ ], n) = n %(h_nil_nTrec2)% 

• h{NT :: 7L, n) = max {height {NT) ^ h{K^ n)) %(n_cons_nTrec2)% 

• height {leaf {x)) = 1 %( height _ leaf _nTrec2)% 

• height {nTree{L)) = h{L^ 0 ) 1 % (height _nTree_nTrec2)% 

• height {nil) = 0 % (height _nil_nTrec2)% 

• /([ ]) = {} %(l_nil_nTree2)% 
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• 1{NT :: K) = leaves(NT) U 1{K) 

• leaves {leaf (x)) = { x } 

• leaves {nTree{L)) = 1{L) 

• leaves {nil) = {} 

end 



% (l_cons_nTree2) % 
% (leaves_leaf_nTree2) % 
% ( leaves _nTree_nTree2) % 
% ( leaves _ nil _nTree2) % 



spec KTree [sort Elem] [op k : Nat] 

given Nat, Set [sort Elem] = %mono 
NTree [sort Elem] 
then %mono 

sort KTree[Elem] = {T: NTree[Elem] • T is k branehing} 

end 



spec KTree2 [sort Elem] [op k : Nat] 

given Nat, Set [sort Elem] = %mono 
NTree2 [sort Elem] 
then %mono 

sort KTree2[Elem] = {T: NTree2[Elem] • T is k branehing} 

end 
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Library Basic/Graphs 



library Basic/ Graphs version 1.0 

%authors : T. Mossakowski <till@tzi.de>, M. Roggenbach, L. Schroder 

%date : 18 December 2003 

%% with contributions from Klaus Liittich 

%{ We construct directed graphs inductively by successively adding 
nodes and edges. 

Ids of nodes must be unique. 

Ids of edges between two given nodes must be unique as well. 

If you need multiple edges with the same label, take a sort 
isomorphic to a product (e.g. Label x Int) as Edgeld. }% 

%display( :: > isin %LATEX :: — > e )% 

%display( isIn %LATEX e )% 

from Basic/StructuredDatatypes get Set, Map, List 

from Basic/Numbers get Nat 

spec Graph [sort Nodeld] [sort Edgeld] = 
generated type 

Graph ::= empty Graph 

I addNode{NodeId; Graph) 

I addEdge{NodeId; Nodeld'^ Edgeld] Graph)? 
ops souree^ target : Edgeld x Graph Nodeld 

preds e : Nodeld x Graph] 

e : Edgeld x Graph] 

:: — > e : Edgeld x Nodeld x Nodeld x Graph 

V n, nl, 5, h tG t2: Nodeld] e, el, e2: Edgeld] p, g': Graph 

• def addEdge{s^ h e^ g) ^ ^ e e g %(dom_addEdge)% 

• ^ n e empty Graph %(isln_empty Graph) % 
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• n e addNode{nl^ g) ^ n = nl V n e g %(isIn_addNode)% 

• n e addEdge{s^ t^e^g)^n=s\/n = t\/neg 

%(isIn_addEdge)% 

• ^ e e empty Graph %(isIn_emptyGraph)% 

• e e addNode{n^ g) e e g %(isIn_addNode)% 

• el e addEdge{s2^ t2^ e2^ g) ^ el = e2 W el e g %(isIn_addEdge)% 

• ^ def souree{e^ empty Graph) 

• souree{e^ addNode{n^ d)) = souree{e^ g) 

• souree{eG addEdge{s^ e2^ g)) = 
s when el = e2 else souree{eG g) 

• ^ def target {e^ empty Graph) 

• target {e^ addNode{n^ g)) = target {e^ g) 

• target {eG addEdge{s^ f e2^ g)) = 
t when el = e2 else target {eG g) 

• e :: s — > t e g 

e e g A souree{e^ g) = s A target{e^ d) = t 

• d = d' ^ 

(V n: Nodeld •negAAneg') A 
(V e: Edgeld •eegAAeeg') A 
(V e: Edgeld • souree{e^ g) = souree{e^ g')) A 

(V e: Edgeld • target {e^ g) = target {e^ g')) %(extensionality)% 

end 

%% Some basic operations and predicates on graphs 
spec RichGraph [sort Nodeld] [sort Edgeld] = 

Graph [sort Nodeld] [sort Edgeld] 
then %def 

ops removeNode : Nodeld x Graph Graph; 

removeEdge : Edgeld x Graph Graph 

V n, n2: Nodeld; e, e4, e2: Edgeld; g': Graph 

• removeNode{n^ empty Graph) = empty Graph 

% (removeNode_emtpy Graph) % 

• removeNode{n^ addNode{nG g)) = 
removeNode{n^ g) 

when n = nl else addNode{nG removeNode{n^ g)) 

% (removcN ode_ addN ode) % 

• removeNode{n^ addEdge{nG n2^ e, g)) = 
removeNode{n^ g) 

when n = nl V n = n2 

else addEdge{nG n2^ e, removeNode{n^ g)) 

%(removeNode_addEdge)% 

• removeEdge{e^ empty Graph) = empty Graph 

% (removeEdge_emtpyGraph) % 

• removeEdge{e^ addNode{nG d)) = addNode{nG removeEdge{e^ g)) 

% (removcEdge_ addNode) % 



% ( sour ce_ empty ) % 
% (source_addNode) % 

% (source_addEdge) % 
% (target _empty) % 
%(target_addNode)% 

% (target _addEdge)% 

%(isln_def)% 
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• removeEdge{e^ addEdge{nl^ n2^ e4, g)) = 
removeEdge{e^ g) 

when e = el else addEdge{nl^ n2^ e4, removeEdge{e^ g)) 

% (removeEdge_addEdge) % 

pred symmetrie{g: Graph) 

V n2: Nodeld; e: Edgeld 

• e :: nl — > n2 e g ^ 

(3 e': Edgeld • e' :: n2 — > nl e g) %(symmetric_def)% 
pred transitive{g: Graph) 

V n2^ n3: Nodeld'^ e4, e2: Edgeld 

• el :: nl — > n2 e g A 
e2 :: n2 — > n3 e g ^ 

(3 e3: Edgeld • e2 :: nl — > n3 e g) %(transitive_def)% 
pred loopEree{g: Graph) AA 

^ 3 n: Nodeld; e: Edgeld • e :: n — > n e g %(loopEree_def)% 
pred simple{g: Graph) AA 

V e4, e2: Edgeld; 5, t: Nodeld 

• el :: s — > t e g A e2 :: s — > t e g ^ 

el = e2 %(simple_def)% 

pred subgraphOf {gG g2: Graph) AA 

(V n: Nodeld • n e gl n e g2) A 
(V n2: Nodeld; e: Edgeld 

• e :: nl — > n2 e gl ^ 

e :: nl > n2 e g2) %(subgraphOf_def)% 

pred eomplete{g: Graph) AA 

V n2: Nodeld 

• nl e g A n2 e g ^ {3 e: Edgeld • e :: nl — > n2 e g) 

%(complete_def)% 

pred eliqueOf {gG g2: Graph) AA 

gl subgraphOf g2 A eomplete{gl) %(cliqueOf_def)% 

pred maxGliqueOf {gO g2: Graph) AA 

gl eliqueOf g2 A 
(V g3: Graph 

• gl subgraphOf g3 A g3 eliqueOf g2 ^ gl = g3) 

%(max_cliqueOf_def)% 

end 

%% Mapping our representation to a set-based one 
spec GraphToSet [sort Nodeld] [sort Edgeld] = 

Graph [sort Nodeld] [sort Edgeld] 

and 

%% The following also imports Set [Edgeld] and Set [Nodeld] 

Map [sort Edgeld] [sort Nodeld] 
then %def 

ops nodeSet : Graph Set[NodeId]; 
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sourceMap^ targetMap : Graph Map[EdgeId^NodeId] 

V g: Graph; n: Nodeld; e: Edgeld 

• n e nodeSet(g) n e g %(nodeSet_def)% 

• [ n / e ] e sourceMap{g) source{e^ g) = n %(sourceMap_def)% 

• [ n / e ] e targetMap{g) target {e^ g) = n %(targetMap_def)% 

then %def 

ops edgeSet : Graph Set[EdgeId]; 

successors^ predecessors : Nodeld x Graph Set[NodeId]; 
inEdges^ outEdges : Nodeld x Graph Set[EdgeId\; 
inDegree^ outDegree : Nodeld x Graph Nat 

V n, n2: Nodeld; e: Edgeld; g: Graph 

• e e edgeSet{g) ^ e e g 

• n2 e successors{nG d) ^ 

3 e: Edgeld • e :: nl — > n2 e g 

• nl e predecessors {n2^ g) 

3 e: Edgeld • e :: nl — > n2 e g 

• e e inEdges{nG g) ^ 

3 n2: Nodeld • e :: n2 — > nl e g 

• e e outEdges{nG g) ^ 

3 n2: Nodeld • e :: nl — > n2 e g 

• inDegree{n^ 5') = tt inEdges{n^ g) 

• outDegree{n^ 5') = tt outEdges {n^ g) 

end 

%% The subsort of symmetric (= undirected) graphs 
spec SymmetricGraph [sort Nodeld] [sort Edgeld] = 

Graph [sort Nodeld] [sort Edgeld] 

then 

sort SymmetricGraph = {g: Graph 

• V 5, t: Nodeld; e: Edgeld 
• e :: s — > t e g 
e :: t — > s e g} 

% (SymmetricGraph_def) % 

type SymmetricGraph ::= empty Graph 

I addNode {node:? Nodeld; 

graph : ? Symmetric Graph) 

I addEdgeSym{source^ target:? Nodeld; 
edge:? Edgeld; 
graph:? SymmetricGraph) 

preds e : Nodeld x SymmetricGraph; 

:: — > e : Edgeld x Nodeld x Nodeld x 

Symmetric Graph 



%(edgeSet_def)% 

% (successors_def) % 

% (predecessors_def) % 

%(inEdges_def)% 

% (outEdges_def) % 
% (inDegree_def) % 
% (outDegree_def) % 
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V 5, t: Nodeld; e: Edgeld; g: SymmetricGraph 

• addEdgeSym{s^ e, g) = 

addEdge{s^ e, addEdgeit^ 5 , e, p)) as SymmetricGraph 

%(addEdge_def)% 

%% the other operations and predicates are determined 
%% by the overloading relations 

end 

spec SymmetricClosure [sort Nodeld] [sort Edgeld] = 

RichGraph [sort Nodeld] [sort Edgeld] 

then 

op sc : Graph Graph 

V n, n2: Nodeld'^ e: Edgeld; g: Graph 

• n e sc{g) ^ n e g %(sc_def_l)% 

• e :: nl — > n2 e sc{g) 

e :: nl — > n2 e g V e :: n2 — > nl e g 

%(sc_def_2)% 

then %implies 

V g: Graph 

• symmetric{sc{g)) %(symmetric_sc)% 

end 

%% Various things defined in terms of paths and transitive closure 
spec Paths [sort Nodeld] [sort Edgeld] = 

RichGraph [sort Nodeld] [sort Edgeld] 

and 

List [sort Edgeld] 

and 

SymmetricGlosure [sort Nodeld] [sort List\EdgeId\[ 
with sort Graph ^ PathGraph 

then 

ops source^ target : List[EdgeId] x Graph -^7 Nodeld; 
tc^ stc : Graph PathGraph 

preds pathOf : List[EdgeId] x Graph; 

paths ubgraphOf : Graph x PathGraph; 

pathTransitive : PathGraph 

V n, n2: Nodeld; e: Edgeld; p: List[EdgeId]; g: Graph; 
g': PathGraph 

• source {p^ g) = source {fir st{p)^ g) 

• target {p^ g) = t ar get {last {p)^ g) 

• g path Sub graph Of g' 

(V n: Nodeld •neg<=^neg^) A 
(V nfi n2: Nodeld; e: Edgeld 
• e :: nl — > n2 e g AA [ e ] :: nl — > n2 e g') 

%(pathSubgraphOf_def)% 
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• pathTransitive{g') 

V n2^ n3: Nodeld; e4, e2: List[EdgeId] 

• el :: nl — > n2 e g' f\ 
e2 :: n2 — > nS e g' ^ 

{el ++ e2) :: nl > nS e g' %(pathTransitive_def)% 

• pathTransitive{te{g)) %(tc_defl)% 

• g paths ubgraphOf te{g) %(tc_def2)% 

• g pathSubgraphOf g' A pathTransitive{g') ^ te{g) subgraphOf g' 

%(tc_def3)% 

• p pathOf g p e te{g) %(pathOf_def)% 

• ste{g) = se{te{g)) %(stc_def)% 

%% Connectedness and acyclity can be elegantly expressed 

%% using (symmetric) transitive closure 

pred eonneeted{g: Graph) eomplete{ste{g)) %( connect ed_def)% 

pred strongly Conneeted{g: Graph) eomplete{te{g)) 

% (stronglyconnected_def) % 
pred aeyelie{g: Graph) loopFree{te{g)) %(acyclic_def)% 

pred hasGyele{g: Graph) ^ aeyelie{g) %(hasCycle_def)% 

%% A tree is an acyclic graph with a root node, such that each 
%% other node is reachable via a unique path from the root 
pred tree{g: Graph) 
aeyelie{g) A 
(3 root: Nodeld 

• root e g A 

(V n: Nodeld 
• negA^n = root ^ 

(3! p: List[EdgeId] 

• p pathOf g A souree{p^ g) = root A target {p^ g) = n))) 

%(tree_defl)% 

%% A spanning tree is a tree subgraph that has the same nodes 

pred spanning Tree Of (t, g: Graph) AA 

tree{t) A t subgraphOf g A ifJ n: Nodeld •neg^net) 

% (spanning_tree_def) % 

%% a symmetric graph is hasCycle iff there is a path that is a cycle 
%% and that does not contain a two- loop 
pred symmetrieHasGyele{g: Graph) AA 
symmetrie{g) A 
(3 p: List[EdgeId]; e: Edgeld 

• p pathOf g A 
freq{p^ e) = 2 A 

^ 3 e4, e2: Edgeld-^ n2: Nodeld 
•el e p A 
e2 e p A 

el :: nl — > n2 e g A 

e2 :: n2 > nl e g) %(symmetricHasCycle_def)% 
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pred symmetricAcyclic{g: Graph) 

symmetric{g) A ^ symmetricHasCycle{g) 

% (symmetricAcyclic_def) % 

pred symmetricTree{g: Graph) 

symmetricAcyclic{g) A connected{g) %(symmetricTree_def)% 

then %implies 

%% finite trees are finite acyclic connected graphs with no 
%% occurrences of -> * <- 
pred tree{g: Graph) 
acyclic{g) A 
connected{g) A 

^ 3 e7, e2: Edgeld; n2^ nS: Nodeld 

• el :: nl — > n2 e g A 
e2 :: n3 — > n2 e g 

%(tree_def2)% 

end 

spec GraphColorability [sort Nodeld] [sort Edgeld] 
given Nat = 

GraphToSet [sort Nodeld] [sort Edgeld] 

and 

Map [sort Nodeld] [sort Nat] 

then 

pred is eolorable{g: Graph; n: Nat) AA 

3 f: Map[NodeId,Nat] 

• dom{f) = nodeSet(g) A 
(V m: Nat •me range{f) ^ m < n) A 
(V e: Edgeld; 5, t: Nodeld 

• e :: s — > t e g ^ ^ lookup{s^ f) = lookup{h /)) 

%(colorable_def)% 

pred bipartite{g: Graph) AA g is 2 eolorable %(bipartite_def)% 

end 

%% Shortest paths in graphs having weights for their edges 
%% Note that the weight function is given globally 
%% If edge Ids should be e.g. integers, then Edgeld should 
%% consists of pairs (id, weight) of integers and naturals 
spec ShortestPaths [sort Nodeld] 

[sort Edgeld 

op weight : Edgeld Nat] 

given Nat = 

Paths [sort Nodeld] [sort Edgeld] 

then 

ops distanee : List[EdgeId] Nat; 

shortestPath : Nodeld x Nodeld x Graph -^1 List[EdgeId] 
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V 5, t: Nodeld; e: Edgeld; p: List[EdgeId]; g: Graph 

• distanced ]) — 0 %(distance_nil)% 

• distance{e :: p) = weight{e) + distance(p) %(distance_cons)% 

• def shortestPath{s^ h g) ^ 

3 p: List[EdgeId] 

• p pathOf g A source{p^ g) = s A target {p^ d) = t 

% (shortestPath_dom) % 

• def shortestPath{s^ h g) A 
p path Of g A 

source{p^ g) = s A 
target {p, g) = t ^ 

distance{shortestPath{s, t, g)) < distance(p) %(shortestPath_def)% 

end 

spec GraphHomomorphism [sort Nl] [sort El] [sort N2] [sort E2] = 
Graph [sort Nl] [sort El] with Graph ^ Graphl 

and 

Graph [sort N2] [sort E2] with Graph ^ Graph2 

and 

Map [sort Nl] [sort N2] 

and 

Map [sort El] [sort E2] 

then 

free type 

PreHom ::= preHom{source: Graphl; target: Graph2; 

nodeMap : Map [Nl , N2 ] ; edgeMap : Map [EGE2]) 
sort Horn = {h: PreHom 

• V n, n': Nl ; e: El 

• e :: n — > n' e source{h) ^ 

lookup {e^ edgeMap{h)) :: lookup {n^ nodeMap {h)) 

— > lookup {nd nodeMap ih)) e target (h)} 

%(Hom_def)% 

end 

%% A minor of a graph is something that can be homomorphically 
%% mapped to the transitive closure 

spec Minor [sort Nl] [sort El] [sort N2] [sort E2] = 

Paths [sort N2] [sort E2] with Graph ^ Graph2 

and 

GraphHomomorphism [sort Nl] [sort El] [sort N2] 

[sort List[E2\\ 
with Graph2 ^ PathGraph 



then 
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pred minorOf {gl: Graphl; g2: Graph2) 

3 h: Horn • source(h) = ql A tarqet(h) = stc(q2) 

%(minorOf_def)% 

end 

%% The complete graph over five nodes 

spec K5 = 

free types 

Five ::= 1 \ 2 \ 3 \ 4 \ ^ 

Five Pair ::= pair {Five‘s Five) 

then 

RichGraph [sort Five] [sort FivePair] 

then 

op k5 : Graph 

V n, n2: Five 

• simpleikd) 

• n e k5 

• pair{nG n2) :: nl — > n2 e k5 

end 

%% The graph consisting of two copies of three nodes, 

%% such that two nodes are linked by an edge iff they stem 
%% from different copies 
spec K3_3 = 

free type Three ::=1 \ 2 \ 3 

free type Three2 ::= left{Three) \ right{Three) 

free type ThreePair ::= pair {Three; Three) 

then 

RichGraph [sort Three2] [sort ThreePair] 

then 

op k3_3 : Graph 

V n, n2: Three 

• simple{k3_3) 

• left{n) e k3_3 %(k3_3_def_l)% 

• right{n) e k3_3 %(k3_3_def_2)% 

• pair{nG n2) :: left{nl) — > right{n2) e k3_3 

%(k3_3_def_3)% 

end 

%% planar graphs defined using the Kuratowski characterization: 

%% K5 and K3_3 must not occur as minors 
spec Planar [sort Nodeld] [sort Edgeld] = 

K5 with Graph ^ Graphd 

and 

K3_3 with Graph ^ Graph3_3 



% (k5_simple) % 
%(k5_def_l)% 
%(k5_def_2)% 
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and 

Minor [sort Five] [sort FivePair] [sort Nodeld] [sort Edgeld] 
with Graphl ^ Graphd^ Graph2 ^ Graph 

and 

Minor [sort Three2] [sort ThreePair] [sort Nodeld] [sort Edgeld] 
with Graphl ^ Graphs _3^ Graph2 ^ Graph 

then 

pred planar{g: Graph) ^ k5 minorOf g A ^ k3_3 minorOf g 

% (planar _def)% 

end 

%% Graphs with edge labels that need not be unique 

%% The trick is to make them unique by adding the source and target node 
spec NonUniqueEdgesGraph [sort Nodeld] [sort EdgeLahel] = 
free type Edgeld ::= El {Nodeld; EdgeLahel; Nodeld) 

then 

RichGraph [sort Nodeld] [sort Edgeld] 

then 

ops addEdge : 

Nodeld X Nodeld x EdgeLahel x Graph Graph; 
removeEdgeLahel : EdgeLahel x Graph Graph 
preds e : EdgeLahel x Graph; 

EdgeLahel x Nodeld x Nodeld x Graph 
V n, n2: Nodeld; e/, el': EdgeLahel; g: Graph 

• addEdge{nG n2^ e/, g) = addEdge{nG n2^ EI{nG e/, n2)^ g) 

% (addEdgcNU_def) % 

• el' e removeEdgeLahel{el^ g) el' e g A ^ el = el' 

%(removeEdgeLabel_defl)% 

• n e removeEdgeLahel{el^ g) ^ n e g %(removeEdgeLabel_def2)% 

• el e g 4=^ 3 n2: Nodeld • EI{nG e/, n2) e g %(isInNUl_def)% 

• el :: nl — > n2 e g EI{nG e/, n2) e g %(isInNU2_def)% 



end 
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library Basic/ Algebra_II version 1.0 

%authors : L. Schroder <lschrode@tzi.de>, M. Roggenbach, T. Mossakowski 
%date : 21 May 2003 
%prec({__*__} < 

%prec({__+__, 

%left_assoc( + , * , " )% 



from Basic/Relations AndOrders get 

PreOrder, TotalOrder, EquivalenceRelation 

from Basic/ Algebra_I get 

Monoid, CommutativeMonoid, Group, CommutativeRing, 
IntegralDomain, RichIntegralDomain, Field, ExtMonoid, 
ExtGroup, ExtGommutativeRing 

from Basic/Numbers get Nat, Int 

from Basic/ StructuredDatatypes get List, Bag 

spec EuclidianRing = 

IntegralDomain 

and 

Nat reveal pred < 

then 

op delta : Elem -^1 Nat 
y a^ b: Elem 

• def delta{a) if ^ a = 0 %(delta_dom_ER)% 
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• (3 g, r: Elem •a = q^h^r/\{r=Oy delta{r) < delta{b))) 

if ^ b = 0 %(div_ER)% 

end 

spec ConstructFactorialRing = 

RichIntegralDomain 

with sorts RUnit[Elem]^ Irred[Elem]^ pred associated 

then %mono 

Bag [sort Irred[Elem]] 

with sort Bag[Irred[Elem]] Eactors[Elem] 

then %def 

pred equivalent : Eactors[Elem\ x Eactors[Elem\ 
op prod : Eactors[Elem\ Elem 

V p j: Irred[Elem\; T: Eactors[Elem] 

• prod{{}) = e %(prod_empty_CFR)% 

• prod{S i) = prod{S) * i %(prod_plus_CFR)% 

• equivalent {S^ T) 

(5 = {} A T = {}) V 
(3 5, t: Irred[Elem] 

• seSAteT A associated{s^ t) A equivalent{S — s^ T — t)) 

% (equivalent _ def _ CFR) % 

then 

V x: Elem] T: Eactors[Elem] 

• 3 F: Eactors[Elem] • x = prod{V) %(existsFact_CFR)% 

• associated{prod{S)^ prod{T)) ^ equivalent{S^ T) 

% (uniqueFact _ CFR) % 

end 

spec FagtorialRing = 

ConstrugtFagtorialRing 
reveal sort Elem^ 

ops + : Elem x Elem 

* : Elem x Elem 

end 

spec IntInfinity = 

Int 

then 

{ free type Intinfty ::= sort Int \ infty \ neginfty 

ops + , * : Intinfty x Intinfty -^1 Intinfty^ 

comm] 

— : Intinfty x Intinfty -^7 Intinfty] 

— : Intinfty Intinfty 

preds < , < : Intinfty x Intinfty 



Elem^ 

Elem^ 0 : Elem^ e : Elem 



then 
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n: Int; m, k: Intinfty 
— infty = neginfty 


%(neg_defl_II)% 


— neginfty = infty 


%(neg_def2_II)% 


neginfty < m 


%(leq_defl_II)% 


m < infty 


%(leq_def2_II)% 


m < neginfty m = neginfty 


%(leq_def3_II)% 


infty < m ^ infty = m 


%(leq_def4_II)% 


m<k^m<kA^m = k 


%(less_def_II)% 


infty + n = infty 


%(add_defl_II)% 


infty + infty = infty 


%ddd_def2_II)% 


def infty + neginfty 


%ddd_def3_II)% 


neginfty X k = — {infty H k) 


%bdd_def4_II)% 


0 < m ^ infty * m = infty 


%(mult defl II)% 


def infty * 0 


%(mult def2 II)% 


— m ^ k = — {m ^ k) 


%(mult_def3_II)% 


m — k = m -\ k 


%(sub def II)% 



}_ 

hide neginfty 

end 

view TotalOrder_in_IntInfinity : 

TotalOrder to IntIneinity = 
sort Elem ^ Intinfty 

end 

spec ConstructPolynomial [CommutativeRing] 
given { Int 
then 

op 0 : Int 
} = %mono 

IntIneinity 

then 

local List [sort Elem] within 

{ %% [a_0,...,a_n] is a_n * x"n + ... + a_0 

sort Poly[Elem] = {/: List[Elem] • ^ last{l) = 0} 

then 

sort Elem < Poly[Elem] 
ops X : Poly[Elem]; 

degree : Poly [Elem] Intinfty; 

::: : Elem x Poly[Elem] Poly[Elem]; 

+ , * • 

Poly[Elem] x Poly[Elem] Poly[Elem] 

V a, b: Elem; p, q: Poly[Elem] 

• X = [ 0, e] %(X_def_Poly)% 

• a = [ ] when a = 0 else [ a ] %(emb_def_Poly)% 
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} 

end 



• a ::: p = a when p = 0 else a :: p %( cons _def_ Poly )% 


• degree {p) = — 


infty when p = 0 else pre{^ p) 




% (degree def Poly)% 


• p 0 = p 


%(add zerol Poly)% 


• 0 p = 0 


%(add_zero2_Poly)% 


• (a ::: P) + (b 


::: q) = {a + h) ::: {p + q) 




% ( add cons Poly ) % 


• p ^ 0 = 0 


% ( mult _ zero 1 _ Poly ) % 


• 0 ^ p = 0 


%(mult zero2 Poly)% 


• (a ::: p) * {b : 


:: q) = 



((a * 6) ::: (6 * p + a * q)) + {0 ::: {0 ::: {p * q))) 

% ( mult _ cons _ Poly ) % 



view CRing_in_CPolynomial [CommutativeRing] given Int : 
CommutativeRing to 

ConstrugtPolynomial [CommutativeRing] = 
sort Eiem ^ Poly[Elem\ 

end 



spec Polynomial [CommutativeRing] given Int = 

ExtCommutativeRing [view CRing_in_CPolynomial 

[CommutativeRing]] 

then %implies 

V p, q: Poly[Elem\ 

• degree{p) < degree{q) ^ degree{p q) < degree{q) 

%( degree _ ad d _ Poly ) % 

• degree {p ^ q) < {degree {p) + degree {q)) %( degr ee_ mult 1_ Poly )% 

• hasNo Zero Divisors degree{p ^ q) = degree{p) + degree{q) 

% ( degree _ mult 2 _ Poly ) % 



end 



view EuglidianRing_in_Polynomial [Field] given Int : 
EuglidianRing to 
{ Polynomial [Field] 

then 

op natDegree : Poly[Elem\ -^1 Nat 
V p: Poly[Elem\ 

• natDegree{p) = degree{p) as Nat %(natDegree_def)% 

} = 

sort Elem ^ Poly[Elem\^ op delta ^ natDegree 

end 



spec MonoidAgtion [Monoid] 
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sort Space 

op * : Elem x Space Space 

V x: Space; a, b: Elem 

• e ^ X = X 

• a^b^x = a^{b^x) 

end 

spec Group Action [Group] = 

MonoidAction [Group] 

end 

spec ExtEuclidianRing [EuclidianRing] given Int = %mono 
RichIntegralDomain 

end 

spec ExtFactorialRing [Factorialring] given Int = 
RichIntegralDomain 

and 

GonstructFactorialRing 

end 

spec ExtMonoidAction [MonoidAction [Monoid]] 
given Nat = %def 
ExtMonoid [Monoid] 

then 

pred connected : Space x Space 

V T, Space 

• connected{x^ y) 3 a: Elem • a ^ x = y 

% (connected_def_EMAction) % 

end 

view PreOrder_in_ExtMonoidAction [MonoidAction [Monoid]] 
given Nat : 

PreOrder to ExtMonoidAction [MonoidAction [Monoid]] = 
sort Elem ^ Space^ pred < ^ connected 

end 

spec ExtGroupAction [GroupAction [Group]] 
given Int = %def 

ExtMonoidAction [GroupAction [Group]] 

and 

ExtGroup [Group] 
then %implies 

V a, 5: Elem; y: Space 

• x = yifa^x = a^y %(inj_EGAction)% 



% ( unit _ M Act ion) % 
% (assoc_MAction) % 
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• 3 z: Space • a ^ z = x %(surj_EG Action) % 

end 

view EqRel_in_ExtGroup Action [GroupAction [Group]] 
given Int : 

EquivalenceRelation to 

ExtGroup Action [GroupAction [Group]] = 

sort Elem ^ Space^ pred ~ ^ connected 

end 

spec RichMonoidAction [Monoid] = 

ExtMonoidAction [MonoidAction [Monoid]] 

end 

view PreOrder_in_RichMonoidAction [Monoid] : 

PreOrder to RichMonoidAction [Monoid] = 
sort Elem ^ Space^ pred < ^ connected 

end 

spec RichGroupAction [Group] = 

ExtGroup Action [GroupAction [Group]] 

end 

view EqRel_in_RichGroup Action [Group] : 

EquivalenceRelation to RichGroupAction [Group] = 
sort Elem ^ Space^ pred ~ ^ connected 

end 

spec RichEuclidianRing = 

ExtEuclidianRing [EuclidianRing] 

end 

spec RichFactorialRing = 

ExtFactorialRing [FactorialRing] 

end 

view FactorialRing_in_ExtEuclRing [EuclidianRing] 
given Int : 

FactorialRing to ExtEuclidianRing [EuclidianRing] 

end 

view FactorialRing_in_RichEuclidianRing : 

FactorialRing to RichEuclidianRing 



end 
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view EuclidianRing_in_Int : 

EuclidianRing to 
{ Int 

then 

op 1 : Int 

} = 

sort Elem ^ Int^ ops delta ^ abs^ e 1 

end 

view FreeMonoid_in_List [sort Elem] given Nat : 

{ sort Generators 

then 

free { Monoid 
then 

op injeet : Generators Elem 

} 

} to 

{ List [sort Elem] 

then 

op singleton{x: Elem): List[Elem] = [ t ] 

} = 

sorts Elem ^ List[Elem]^ Generators ^ Elem^ 
ops e [], * ^ ++ , injeet ^ singleton 

end 

view FreeCommutativeMonoid_in_Bag [sort Elem] 
given Nat : 

{ sort Generators 

then 

free { CommutativeMonoid 

then 

op injeet : Generators Elem 

} 

} to 

Bag [sort Elem] 

sorts Elem ^ Bag[Elem]^ Generators ^ Elem^ 
ops e {}, * ^ U , injeet ^ { } 



end 
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Library Basic/Linear Algebra_I 



library Basic/LinearAlgebra_I version 1.0 

%authors : L. Schroder <lschrode@tzi.de>, M. Roggenbach, T. Mossakowski 
%date : 9 January 2004 

%prec({ * } < { ^ })% 

%prec({__+__, 

%left_assoc( + , * , " )% 



from Basic/ Algebra_I get 

AbelianGroup, ExtAbelianGroup, Monoid, Group, Field, 
ExtField, Richfield 

from Basic/ Algebra_II get 

MonoidAction, RichMonoidAction, GroupAction, 
ExtGroupAction, EuclidianRing_in_Int 

from Basic/Numbers get Nat, Int 

from Basic/ Algebra_II get Polynomial 

from Basic/StructuredDatatypes get Array, Map 

spec VectorSpace [Field] = 

MonoidAction [Monoid 

with ops e, * : Elem x Elem Elem] 

with sort Space^ op * : Elem x Space Space 

then 

closed {AbelianGroup 

with sort Elem ^ Space^ ops e ^ 0^ * ^ +_ 
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} 

then 

y y: Space; a, b: Elem 

• {a yh)^x = a^xyh^x 

• a^{xyy) = a^xya^y 

end 

view AbelianGroup_in_VectorSpace [Field] : 

AbelianGroup to VectorSpace [Field] = 
sort Elem ^ Space^ ops e ^ 0^ * ^ + 

end 

view GroupAction_in_VectorSpace [Field] : 

Group Action [Group] to 
{ VectorSpace [Richfield 

reveal sorts Elem^ NonZero[Elem\^ 
ops e, 0 , + , * ] 

then 

op * : NonZero[Elem\ x Space Space 

} = 

sort Elem NonZero[Elem\ 

end 

view VectorSpace_in_Field [Field] : 

VectorSpace [Field] to Field = 
sort Space ^ Elem^ 

op * : Elem x Space Space ^ 

* : Elem x Elem Elem 

end 

spec VectorSpaceLG [VectorSpace [Field]] = %mono 
Map [sort Space] [sort Elem] 
with sort Map[Space^Elem] ^ LC[Space^Elem] 
hide sorts Set[Space]^ Set[Elem]^ NonEmptySet[Space]^ 

NonEmptySet [Elem] 

then 

op eval : LC[Space^Elem] Space 
pred isZero : L C[S pace ^ Elem] 

V x: Space; r: Elem; 1: LC[Space^Elem] 

• eval{empty) = 0 %( eval_ empty _E VS )% 

• lookup{x^ 1) = r ^ evalil) = r * t + evalil — [ r / x]) 

%(eval_add_EVS)% 

• isZeroil) V Space • lookup {y^ 1) = 0 if def lookup {y^ 1) 

% (isZero_ def _ EVS ) % 



%(distrl_VS)% 

%(distr2_VS)% 



end 
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spec ConstructVSWithBase [Field] [sort Base] 
given Int = %mono 

VectorSpaceLC [VectorSpace [Field]] 

then 

sort Base < Spaee 

then 

Map [sort Base] [sort Elem] 

with sort Map[Base^Elem] ^ LC[Base^Elem] 

hide sorts Set[Base]^ Set[Elem]^ NonEmptySet[Base]^ 

NonEmptySet [Elem] 

then 

sort LC[Base^Elem] < LC[Spaee^Elem] 

V /: LC[Base^Elem] 

• V Spaee •3 k: LC[Base^Elem] • y = eval{k) 

%(generating_CVSB)% 

• eval{l) = 0 ^ isZero{l) % (independent _CVSB)% 

end 

spec VSWithBase [Field] [sort Base] = 

ConstructVSWithBase [Field] [sort Base] 
reveal sorts Spaee^ Elem^ Base^ 

ops + : Spaee x Spaee Spaee^ 0 : Spaee^ 

* : Elem x Spaee Spaee^ 

* : Elem x Elem Elem^ 

+ : Elem x Elem Elem^ 0 : Elem^ e : Elem 

end 

spec ExtVectorSpace [VectorSpace [Field]] 

given Int = %mono 

Richfield 

and 

ExtAbelianGroup [view AbelianGroup_in_VectorSpace 

[Field]] 

with ops inv ^ — , " ^ times , 

and 

RichMonoidAction [Monoid] 

and 

ExtGroup Action [view Group Action_in_VectorSpace 

[Field]] 

and 

VectorSpaceLC [VectorSpace [Field]] 



end 
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spec ExtVSWithBase [VSWithBase [Field] [sort Base]] 
given Int = %mono 

ExtVectorSpace [VSWithBase [Field] [sort Base\[ 

and 

ConstructVSWithBase [Field] [sort Base] 
with sort LC[Base^Elem] 
then %implies 

V /, k: LC[Base^Elem] 

• eval{l) = eval{k) ^ I = k % (unique Repres_EVSB)% 

then %def 

op eoeffieients : Spaee LC[Base^Elem] 

V x: Spaee 

• eval [eoeffieients [x)) = x % (coefficients _def_EVSB)% 

then %implies 

V 1: LC[Base^Elem] 

• eoeffieients {eval{l)) = I %(recoverCoeff_EVSB)% 

end 

spec VectorTuple [VectorSpace [Field]] [op n : Pos] 

given Int = %mono 

{ Array [ops f n : Int fit ops min : Int ^ f max : Int ^ n] 
[sort Spaee] 

hide sorts Set[Spaee]^ Set[Index]^ NonEmptySet[Spaee]^ 
NonEmptySet [Index] 

with sorts Index ^ Index[n]^ Array[Spaee] 
then %def 

sort Index[n] < Nat 

then 

sort Tuple[Spaee^n] = {x: Array[Spaee] 

• y i: Index[n] • def x ! i} 

ops ! : Tuple[Spaee^n] x Index[n] Spaee; 

0 : Tuple[Spaee^n]; 

* : Elem x Tuple[Spaee^n] Tuple[Spaee^n]; 

4 “ ' 

Tuple[Spaee^n] x Tuple[Spaee^n] Tuple[Spaee^n]; 
auxsum : Tuple[Spaee^n] x Index[n] Spaee; 
sum : Tuple[Spaee^n] Spaee 
V r: Elem; x, y: Tuple[Spaee^n]; i: Index[n] 

• 0 \ i = 0 %(0_def_Tuple)% 

• (r ^ x) \ i = r ^ (x \ i) %( mult _ def _ Tuple )% 

• {x y) \ i = {x \ i) {y \ i) %( add _ def _ Tuple) % 

• auxsum{x^ 1 as Index[n]) = x \ 1 as Index[n] 

% ( auxs um _l_Tuple)% 

• auxsum[x^ sue[i) as Index[n]) = 
auxsum{x^ i) + (x ! sue{i) as Index[n]) 
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% ( auxsum _ sue _ Tuple) % 
• sum{x) = auxsum{x^ n as Index[n]) %(sum_def_ Tuple) % 

hide op auxsum 

end 

spec ConstructVector [Field] [op n : Pos] 

given Int = %mono 

VectorTuple [view VectorSpace_in_Field [Field]] 

[op n : Pos] 

with sorts Tuple[Elem^n] ^ Vector[Elem^n]^ Index[n]^ 

ops 0^ * , + , sum 

with op ! : Vector[Elem^n] x Index[n] Elem 

then 

ops < II > : Vector [Elem^n] x Vector[Elem^n\ Elem] 

prod : Vector[Elem^n\ Elem] 

unitVector : Index[n] Vector[Elem^n\] 

auxmult : Vector[Elem^n\ x Vector [Elem^n] Vector[Elem^n\] 

auxprod : Vector[Elem^n\ x Index[n] Elem 
pred orthogonal : Vector[Elem^n] x Vector[Elem^n] 

V x^ y: Vector[Elem^n\] p j: Index[n] 

• auxmult{x^ y) \ i = {x \ i) ^ {y \ i) %( auxmult _def_CVect or )% 

• < X \\ y > = sum{auxmult{x^ y)) %(scp_def_CVector)% 

• auxprod{x^ 1 as Index[n\) = x \ 1 as Index[n\ 

% (auxprod_ 1 _CVector) % 

• auxprod{x^ suc{i) as Index[n\) = 
auxprod {x^ i) ^ {x \ suc{i) as Index[n]) 

% (auxprod_suc_CVector ) % 

• prod{x) = auxprod{x^ n as Index[n]) %(prod_def_CVector)% 

• orthogonal{x^ y)<^<x\\y> = 0 %(orthogonal_def_CVector)% 

• unitVector (i) \ j = e when i = j else 0 %( unitVector _def)% 

sort UnitVector[Elem^n\ = {x: Vector[Elem^n\ 

• 3 L Index[n\ • x = unitVector (i)} 

hide ops auxmulh auxprod 
then %implies 

V x^ y: Vector [Elem^n] 

• <x\\y> = <y\\x> %(scpComm_CVector)% 

• <x\\x> = 0^x = 0 %(scpPos_CVector)% 

end 

spec Vector [Field] [op n : Pos] given Int = 

ConstructVector [Field] [op n : Pos] 
reveal sorts Vector[Elem^n]^ UnitVector[Elem^n]^ 

ops + : 

Vector[Elem^n] x Vector[Elem^n] Vector[Elem^n]^ 
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end 



* : Elem x Vector[Elem^n\ Vector[Elem^n\^ 

0 : Vector [Elem^n] 



view VectorSpace_in_Vector [Field] [op n : Pos] given Nat : 
VectorSpace [Field] to Vector [Field] [op n : Pos] = 
sort Space ^ Vector[Elem^n\ 

end 



spec SymmetricGroup [op n : Pos] given Int = %mono 
sort Index[n] = {i: Pos • i < n} 

then 

Array [ops 4, n : Int fit ops min : Int ^ 4, max : Int ^ n] 

[sort Index[n]] 

with sorts Array [Index[n]]^ Index ^ Index[n] 

then 

sort Perm[n] = {p: Array[Index[n^ 

• Vi: Index[n] • 3 j: Index[n] • p \ j = i} 
ops id : Perm[n]; 

comp : Perm[n] x Perm[n] Perm[n]; 

sign : Perm[n] Int; 
nEac: Nat = n ! 

V p, q: Perm[n]; i: Index[n] 

• id \ i = i 

• {p comp q) \ i = p \ {q \ i) 

• sign{p comp q) = sign{p) * sign{q) 

% (signHomomorphic_SymGroup) % 

• abs{sign{p)) = 4 %(signRange_SymGroup)% 

• 3 r: Perm[n] • sign{r) = — 4 %(signSurj_SymGroup)% 

then %cons 

sort Permlndex[n] = {i: Pos • i < nEac} 
op perm : Permlndex[n] Perm[n] 

V p: Perm[n] 

• 3 i: Permlndex[n] • pcrm{i) = p %(permSurj_SymGroup)% 

end 



%(nFac_def_SymGroup)% 

%(id_def_SymGroup)% 

%(comp_def_SymGroup)% 



view Group_in_SymmetricGroup [op n : Pos] given Nat : 
Group to SymmetricGroup [op n : Pos] = 
sort Elem ^ Perm[n], ops * ^ comp , e id 



end 
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spec Matrix [Field] [op n : Pos] given Int = %mono 
VectorTuple [view VectorSpace_in_Vector 

[Field] [op n : Pos]] 

[op n : Pos] 

with sorts Index[n]^ Tuple[Vector[Elem^n]^n] Matrix[Elem^n] 

and 

ConstructVector [Field] [op n : Pos] 

and 

ExtField [Field] 

then 



then 



ops transpose : Matrix[Elem^n] Matrix[Elem^n]; 

1 : Matrix[Elem^n]; 

elementary : Index[n] x Index[n] Matrix[Elem^n]; 

* : Matrix[Elem^n] x Veetor[Elem^n] Veetor[Elem^n\^ 

* : Matrix[Elem^n] x Matrix[Elem^n] Matrix[Elem^n]; 

det : Matrix[Elem^n] Elem 
y a^ b: Matrix[Elem^n]; x: Veetor[Elem^n]; p j, k: Index[n] 

• {transpose(a) \ i) \ j = {a \ j) \ i %(transpose_def_Matrix)% 

• [1 \ i) \ j = e when i = j else 0 %(l_def_Matrix)% 

• elementary {p j) \ k = unitVeetor{j) when i = k else 0 

%( element ary _ def_ M at rix ) % 

• {a ^ x) \ i = < transpose(a) ! i || t > %(scalmult_def_Matrix)% 

• {a ^ b) \ i = a ^ {b \ i) %(mult_def_Matrix)% 

sort Element ary Matrix[Elem^n] = {x: Matrix[Elem^n] 

• 3 j: Index[n] 

• X = elementary {p j)} 



local 

SymmetricGroup [op n : Pos] 

with sorts Perm[n], Permlndex[n]^ ops sign^ perm^ nEae 

then 

closed ConstructVector [Field] 

[op nEae : Pos] 

with sorts Veetor[Elem^nEae]^ 

Index[nEae] Permlndex[n] 

then 

ops summands : Matrix[Elem^n] Veetor[Elem^nEae]; 
faetors : 

Matrix[Elem^n] x Permlndex[n] Veetor[Elem^n] 

within 

V a: Matrix[Elem^n]; i: Index[n]; j: Permlndex[n] 

• faetors {a^ j) \ i = {a \ i) \ {perm{j) ! i) % (fact ors _def_ Mat rix) % 

• summands {a) ! j = prod {faetors {a^ j)) times sign{perm{j)) 

%(summands_def_Matrix)% 

• det (a) = sum{summands{a)) % (Leibnitz) % 
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then %implies 

W b: Matrix[Elem^n] 

• det{0) = 0 

• ^ det{a) = 0 y x: Vector[Elem^n\ • x 

• det{l) = e 

• det{a * 6) = det{a) * det{b) 

end 

spec RichVectorSpace = 

ExtVectorSpace [VectorSpace [Field]] 

end 

spec RichVSWithBase [Field] [sort Base] = 

ExtVSWithBase [VSWithBase [Field] [sort Base]] 

end 

view VectorSpace_in_VectorTuple [VectorSpace [Field]] 

[op n : Pos] 

given Int : 

VectorSpace [Field] to 

VectorTuple [VectorSpace [Field]] [op n : Pos] = 
sort Spaee ^ Tuple[Spaee^n] 

end 

view VSWithBase_in_Field [ Field 

then 

op a : Elem 
• ^ a = 0 ] : 

VSWithBase [Field] [sort Base] to 
{ Field 

then 

sort Singleton[a] = {x: Elem • x = a} 

} = 

sorts Spaee Elem^ Base ^ Singleton[a]^ 

op * : Elem x Spaee Spaee 

* : Elem x Elem Elem 

end 

view VSWithBase_in_Vector [Field] [op n : Pos] given Nat : 
VSWithBase [Field] [sort Base] to 
Vector [Field] [op n : Pos] = 

sorts Spaee Veetor[Elem^n]^ Base ^ UnitVeetor[Elem^n] 



%(detO)% 
0 if a ^ X = 0 

% (det Vanishes) % 
%(detl)% 
%( det Mult )% 



end 
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view VSWithBase_in_Matrix [Field] [op n : Pos] given Nat : 

VSWithBase [Field] [sort Base] to Matrix [Field] [op n : Pos] = 
sorts Space ^ Matrix[Elem^n]^ Base ^ Elementary Matrix[Elem^n] 

end 

%% The following view expresses that every vector space has a base. 

%% This holds because the CASE semantics assumes the axiom of choice, 
view VSWithBase_in_VectorSpace [Field] given Int : 
{VSWithBase [Field] [sort Base] hide sort Base} to 
VectorSpace [Field] 

end 




10 



Library Basic/Linear Algebra_II 



library Basic/LinearAlgebra_II version 1.0 

%authors : L. Schroder <lschrode@tzi.de>, M. Roggenbach, T. Mossakowski 
%date : 9 January 2004 

%prec({ * } < { ^ })% 

%prec({__+__, 

%left_assoc( + , * , " )% 



from Basic/Numbers get Nat, Int 

from Basic/ Algebra_I get Field, Richfield, Ring, ExtRing 

from Basic/ Algebra_II get Polynomial 

from Basic/LinearAlgebra_I get 

VectorSpace, VSWithBase, ExtVectorSpace, Matrix 

spec Free VectorSpace [Field] [sort Base] = %mono 
free { VectorSpace [Field] 

then 

op inject : Base Space 

} 

end 

spec Algebra [Field] = 

VectorSpace [Field] 



+ , * 



and 



closed {Ring 

with sort Elem ^ Space^ ops 



, 0, e} 
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then 

sort Elem < Space 

V r: Elem; x, y: Space 

• r^x^y = r^{x^y) 

• X ^ (r ^ y) = r ^ (x ^ y) 

end 

spec FreeAlgebra [Field] = 

free { Algebra [Field] 

then 

op X : Space 

} 

end 

spec ExtFreeVegtorSpage [FreeVegtorSpage [Field] 

[sort Base]] 

given Int = 

ExtVegtorSpage [FreeVegtorSpage [Field] [sort Base]] 

end 

spec ExtAlgebra [Algebra [Field]] given Int = %mono 
RighField 

and 

ExtVegtorSpage [VegtorSpage [Field]] 

and 

ExtRing [Algebra [Field] fit sort Elem ^ Space] 

and 

Polynomial [Field] 

then 

op eval : Poly[Elem] x Space Space 

V a: Elem; p: Poly [Elem]; x: Space 

• eval{0^ x) = 0 %(eval_0_E Algebra) % 

• eval{a ::: p, t) = a + eval{p^ x) ^ x %(eval_cons_EAlgebra)% 

end 

spec ExtFreeAlgebra [Field] given Int = 

ExtAlgebra [FreeAlgebra [Field]] 

end 

view Algebra_in_ Matrix [Field] [op n : Pos] given Nat : 

Algebra [Field] to Matrix [Field] [op n : Pos] = 
sort Space ^ Matrix[Elem^n]^ op e ^ 1 

end 

spec RighAlgebra [Field] = 



%(leftLinear_Algebra)% 

%(rightLinear_Algebra)% 
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ExtAlgebra [Algebra [Field]] 

end 

spec RighFreeVegtorSpage [Field] [sort Base] = 

ExtFreeVegtorSpage [FreeVegtorSpage [Field] [sort Base]] 

end 

spec RighFreeAlgebra [Field] = 

ExtFreeAlgebra [Field] 

end 

%% The following view expresses that a vector space is free over 
%% any of its bases 

view FreeVegtorSpage_in_VSWithBase [Field] given Int : 
FreeVegtorSpage [Field] [sort Base] to 
{ VSWithBase [Field] [sort Base] 
then 

op injeet : Base Spaee 
V x: Base 

• injeet {x) = x % (inject _def_VSB)% 

} 

end 

view FreeAlgebra_in_Polynomial [Field] given Int : 

FreeAlgebra [Field] to Polynomial [Field] = 
sort Spaee ^ Poly[Elem] 



end 
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Library Basic/ MachineNumbers 



library Basic/MachineNumbers version 1.0 

%authors : T. Mossakowski <till@tzi.de>, M. Roggenbach, L. Schroder 
%date : 25 June 2003 

%{ This library contains specifications of those subtypes 
of the naturals and the integers that are used on actual 
machines. 

The specifications CARDINAL and INTEGER provide subtypes 
of Nat and Int consisting of those numbers that have 
a binary representation within a given word length. 

Operations on these data types are partial restrictions 
of the usual operations on Nat and Int - they are undefined 
if the word length is exceeded. 

The specification TwoComplement provides a “cyclic” 
version of bounded integers that corresponds to the 
common two complement representation of integers 
used in many programming languages. 

Operations are total here - the successor of the 
maximal positive number fitting in the word length is 
the minimal negative number. 

The Ext versions of the specifications add min and max 
operations (inherited from TotalOrder). }% 



from Basic/Relations AndOrders get 
TotalOrder, ExtTotalOrder 

from Basic/Numbers get Nat, Int 

spec CARDINAL [op WordLength : Nat ] given Nat = %mono 
Nat 
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then %mono 

%% Define CARDINAL to be isomorphic to the subset 
%% 0.. 2"WordLength-l of Nat 
%% using a partial constructor natToCard 

type CARDINAL ::= natToCard{cardToNat:Nat)l 

V x: NaC c: CARDINAL 

• def natToCard(x) x < {2 " WordLength — ? 1) 

%(natToCard_dom)% 

• natToCard{cardToNat{c)) = c %(natToCard_def)% 

then %def 

%% The predicates and operations are just inherited from Nat, 

%% but operations may become partial, since natToCard is partial 
pred < : CARDINAL x CARDINAL 

V X, y: CARDINAL 

• X < y cardToN at{x) < cardToNat(y) %(leq_ CARDINAL )% 

then %def 

ops maxCardinal : Nat; 

0^ 4, maxCardinal : CARDINAL; 

+ , — , * , div , mod : 

CARDINAL X CARDINAL CARDINAL 



• maxCardinal = 2 " WordLength —11 %(maxCardinal_Nat)% 

• maxCardinal = natToCard (maxCardinal) 

% (maxCardinal_ CARDINAL ) % 



V X, y: CARDINAL 

• natToCard(O) = 0 %(def_0_CARDINAL)% 

• natToCard{l) = 1 %(def_l_CARDINAL)% 

• X N y = natToCard{cardToNat{x) + cardToNat(y)) 

%(add_CARDINAL)% 

• X — y = natToCard (cardToN at (x) — ? cardToNat(y)) 

%(sub_CARDINAL)% 

• X ^ y = natToCard{cardToNat{x) * cardToNat(y)) 

%(mult_CARDINAL)% 

• X div y = natToCard{cardToNat{x) div cardToN at{y)) 

%(div_CARDINAL)% 

• X mod y = nat To Card {cardToN at (x) mod cardToN at (y)) 

%(mod_CARDINAL)% 



then %implies 

ops + : CARDINAL x CARDINAL -^1 CARDINAL, 



assoc, comm, unit 0; 

* : CARDINAL x CARDINAL -^1 CARDINAL, 

assoc, comm, unit 1 
V X, y: CARDINAL 

• def X y ^ { cardToN at (x) + cardToN at (y)) < maxCardinal 

%(add_CARDINAL_dom)% 

• def x-y^y<x %(sub_CARDINAL_dom)% 
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• def X ^ y ^ {cardToNat(x) * cardToNat(y)) < maxCardinal 

%(mult_CARDINAL_dom)% 

• def X div y ^ ^ y = 0 %(div_CARDINAL_dom)% 

• def X mod y ^ y = 0 %(mod_CARDINAL_dom)% 

end 



spec INTEGER [op WordLength : Nat] given Nat = %mono 
Int 



then %mono 



%% Define INTEGER to be isomorphic to the subset 
%% -2^(WordLength-l)..2^(WordLength-l)-l of Int 
%% using a partial constructor intToInteger 

type INTEGER ::= intToInteger{integerToInt:Int)l 
V t: Int; i: INTEGER 

• def intToInteger{x) 

— {2 " {WordLength — ? 4)) < x 

A X < {2 " {WordLength — ? 1) — 1) 

% (intToInteger _dom) % 

• intToInteger {integerToInt{i)) = i %(intToInteger_def)% 

then %def 

%% The predicates and operations are just inherited from Int, 

%% but operations may become partial, since intToInteger is partial 

pred < : INTEGER x INTEGER 

x,y: INTEGER 

• X < y AA integerToInt{x) < integer To Int {y) %(leq_INTEGER)% 

then %def 

ops maxlnteger^ mininteger : Int; 

0^ 4, maxlnteger^ mininteger : INTEGER; 

- ,ahs: INTEGER INTEGER; 

+ , — , * , / , div , mod , 



quot , rem : 

INTEGER X INTEGER INTEGER 

• maxinteger = 2 " {WordLength —1 1) — 1 %(maxlnteger_lnt)% 

• mininteger = — {2 {WordLength — ? 1)) %(minlnteger_lnt)% 

• maxinteger = intToInteger {maxinteger) 

% (maxinteger _INTEGER) % 

• mininteger = intToInteger {mininteger) 

% (mininteger _INTEGER) % 



V T, INTEGER 

• intToInteger{0) = 0 %(def_0_INTEGER)% 

• intToInteger{l) = 1 %(def_l_INTEGER)% 

• — X = intToInteger {— integerToInt{x)) %(minus_INTEGER)% 

• abs{x) = intToInteger {abs {integer ToInt{x))) %(abs_INTEGER)% 

• X y = intToInteger {integerToInt{x) + integerToInt{y)) 



%(add_INTEGER)% 
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• X — y = intToInteger{integerToInt{x) — integerToInt{y)) 

%(sub_INTEGER)% 

• X ^ y = intTo Integer {integer To Int{x) * integerToInt{y)) 

% (mult _INTEGER) % 

• X j y = intTo Integer {integer To Int{x) /? integerToInt{y)) 

% (divide_INTEGER) % 

• X div y = intToInteger{integerToInt{x) div integerToInt{y)) 

%(div_INTEGER)% 

• X mod y = intTo Integer {integer To Int{x) mod integerToInt{y)) 

% (mod_INTEGER) % 

• X quot y = intTo Integer {integer To Int{x) quot integerToInt{y)) 

%(quot_INTEGER)% 

• X rem y = intToInteger{integerToInt{x) rem integerToInt{y)) 

% (remINTEGER) % 



then %implies 

ops + : INTEGER x INTEGER INTEGER, 



assoe, eomm, unit 0; 

* : INTEGER x INTEGER INTEGER, 



end 



assoe, eomm, unit 1 
y x,y: INTEGER 

• def — X {mininteger -\- 1) < integerToInt{x) 

% (minus_INTEGER_dom) % 

• def abs{x) {mininteger -\- 1) < integerToInt{x) 

% (abs_INTEGER_dom) % 

• def X y ^ 

mininteger < {integer To Int{x) + integer To Int{y)) A 
{integer To Int{x) + integerToInt{y)) < maxinteger 

% (add_INTEGER_dom) % 



• def X — y 

mininteger < {integer To Int{x) — integerToInt{y)) A 
{integer To Int{x) — integerToInt{y)) < maxinteger 

% (sub_INTEGER_dom) % 



def X ^ y ^ 

mininteger < {integer To Int{x) * integerToInt{y)) A 
{integer To Int{x) * integer To Int{y)) < maxinteger 

%(mult_INTEGER_dom)% 

def X / y ^ def intToInteger{integerToInt{x) /? integerToInt{y)) 

%(divide_INTEGER_dom)% 
def X div y ^ ^ y = 0 %(div_INTEGER_dom)% 

def X mod y ^ y = 0 %(mod_INTEGER_dom)% 

def X quot y ^ ^ y = 0 %(quot_INTEGER_dom)% 

def X rem y ^ ^ y = 0 %(rem_INTEGER_dom)% 



spec TwoComplement [op WordLength : Nat] 
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given Nat = %mono 

Int 

then %mono 

%% Define TwoComplement to be isomorphic to the subset 
%% -2^(WordLength-l)..2^(WordLength-l)-l of Int 
%% using a total constructor intToTC 
%% The constructor can be total because integers are 
%% taken modulo 2"WordLength 

generated type TwoComplement ::= intToTC{Int) 
ops maxlnteger^ mininteger : Int; 

TCtoInt : TwoComplement Int 

• maxinteger = 2 " {WordLength —7 1) — 1 %(maxlnteger_lnt)% 

• mininteger = — (2 {WordLength — ? 1)) %(minlnteger_lnt)% 

V T, y: Int; i: TwoComplement 

• intToTC(x) = intToTC{x + ^ " WordLength) %(cycle_max)% 

• intToTC{x) = intToTC{y) ^ x — y mod 2 " WordLength = 0 

% (cycle_min) % 

• TCtoInt{intToTC{x)) = x if mininteger < x A x < maxinteger 

then %def 

%% The predicates and operations are just inherited from Int. 

%% Operations remain total, since intToTC is total 

pred < : TwoComplement x TwoComplement 

y x^ y: TwoComplement 

• X < y AA TCtoInt(x) < TCtoInt{y) %(leq_TwoComplement)% 

then %def 

ops 0^ C maxinteger^ mininteger : TwoComplement; 

— , ahs : TwoComplement TwoComplement; 

+ , — , * , / , div , mod , 

quot , rem : 

TwoComplement x TwoComplement TwoComplement 

• maxinteger = intToTC {maxinteger) 

% (maxinteger _ TwoComplement ) % 

• mininteger = intToTC {mininteger) 

% (mininteger _ TwoComplement ) % 

y x^ y: TwoComplement 

• intToTC {0) = 0 %(def_0_ TwoComplement )% 

• intToTC {!) = 1 %(def_l_TwoComplement)% 

• — X = intToTC {— TCtoInt{x)) %( minus _ TwoComplement )% 

• abs{x) = intToTC {abs {TCtoInt {x))) %( abs_ TwoComplement )% 

• X y = intToTC {TCtoInt {x) + TCtoInt {y)) 

%( add _ TwoComplement )% 

• X — y = intToTC {TCtoInt {x) — TCtoInt{y)) 

% (sub _ TwoComplement ) % 

• X ^ y = intToTC {TCtoInt {x) * TCtoInt {y)) 

% ( mult _ TwoComplement ) % 
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• X ! y = intToTC {TCtoInt{x) /? TCtoInt{y)) 

% ( divide_ TwoComplement ) % 

• X div y = intToTC {TCtoInt{x) div TCtoInt{y)) 

% (div_ TwoComplement ) % 

• X mod y = intToTC {TCtoInt{x) mod TCtoInt(y)) 

% (mod_TwoComplement ) % 

• X quot y = intToTC {TCtoInt{x) quot TCtoInt{y)) 

% ( quot _ TwoComplement ) % 

• X rem y = intToTC {TCtoInt(x) rem TCtoInt(y)) 

%(rem_TwoComplement)% 

end 

view TotalOrder_ IN _ CARDINAL [op WordLength : Nat] 
given Nat : 

TotalOrder to CARDINAL [op WordLength : Nat] = 
sort Elem ^ CARDINAL 

end 

view TotalOrder_in_INTEGER [op WordLength : Nat] 
given Nat : 

TotalOrder to INTEGER [op WordLength : Nat] = 
sort Elem ^ INTECER 

end 

view TotalOrder_in_TwoComplement [op WordLength : Nat] 
given Nat : 

TotalOrder to TwoComplement [op WordLength : Nat] = 
sort Elem ^ TwoComplement 

end 

spec ExtCARDINAL [op WordLength : Nat] given Nat = 

ExtTotalOrder [view TotalOrder_in_CARDINAL 

[op WordLength : Nat]] 

end 

spec ExtINTEGER [op WordLength : Nat] given Nat = 

ExtTotalOrder [view TotalOrder_in_INTEGER 

[op WordLength : Nat]] 

end 

spec ExtTwoComplement [op WordLength : Nat] given Nat = 

ExtTotalOrder [view TotalOrder_in_TwoComplement 

[op WordLength : Nat]] 



end 
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Dependency Graphs of the Libraries 



This chapter contains the dependency graphs for the Basic Libraries. Elliptic 
nodes in the graphs usually denote named specihcations from the library (some 
of them, labeled with Nl, N2, etc., also denote anonymous specihcations, e.g. 
occurring as targets of views). Square nodes denote specihcations that are 
imported from other libraries. Normal solid edges denote references to other 
specihcations, whereas dotted edges denote references occurring in a formal 
parameter or import. Thick solid edges denote views. 



( Nat ) 



Int 






al F raction^ 



Fig. 12.1. Dependency graph for Basic/Numbers 
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Fig. 12.2. Dependency graph for Basic/RelationsAndOrders 
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Fig. 12.3. Dependency graph for Basic/ Algebra_I 
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Fig. 12.4. Dependency graph for Basic/SimpleDatatypes 
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Fig. 12.5. Dependency graph for Basic /StructuredDatatypes 




V:12 Dependency Graphs of the Libraries 



463 




Fig. 12.6. Dependency graph for Basic/Graphs 
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Fig. 12.7. Dependency graph for Basic/ Algebra_II 
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and P. D. Mosses, editors. Recent Trends in Algebraic Development Techniques, 
14th International Workshop, WADT’99, Chateau de Bonas, France, 1999, Se- 
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472 Annotated Bibliography 



Bidoit : 2002 :GDL. 

Michel Bidoit, Donald Sanneha, and Andrzej Tarlecki. Global development 
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Magne Haveraaen. Case study on algebraic software methodologies for scientihc 
computing. Scientific Programming, 8(4):261-273, 2000. 
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Hoffman: 2001 :VAS. 

Piotr Hoffman. Verifying architectural specihcations. In M. Cerioli and G. Reg- 
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Universite d’Evry-Val d’Essonne, Evry, 2000. 

Provides a Casl case study in geometric modeling and presents the 
different useful Casl features for geometric modeling. 
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tural specihcations. In K. Diks and W. Rytter, editors. Mathematical Founda- 
tions of Computer Science 2002, 27th International Symposium, MFCS 2002, 
Warsaw, Poland, Proceedings, LNCS Vol. 2420, pages 506-518. Springer, 2002. 
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logic. In Casl Reference Manual, LNCS Vol. 2960 (IFIP Series), part IV. 
Springer, 2004. Edited by T. Mossakowski. 

Presents proof calculi that support reasoning about Casl specifica- 
tions; proves soundness and discusses completeness. 

Mosses : 1996 : CoFI. 

Peter D. Mosses. CoFI: The Common Framework Initiative for algebraic spec- 
ihcation. Bulletin of the EATCS, 59:127-132, June 1996. An updated version 
is [Mosses : 2001 : CoFI]. 

Presents CoFI, describing the aims and goals. 

Mosses : 1997 :CAS. 

Peter D. Mosses. Casl for Asf+Sdf users. In M. P. A. Sehink, editor, 
ASF+SDF’97, Proc. 2nd Inti. Workshop on the Theory and Practice of Al- 
gebraic Specifications, volume ASFSDF-97 of Electronic Workshops in Com- 
puting. British Computer Society, 1997. 

Gives an overview of Casl, comparing it to AsfRSdf. 

Mosses : 1997 : CoFI. 

Peter D. Mosses. CoFI: The Common Framework Initiative for algebraic speci- 
hcation and development. In M. Bidoit and M. Dauchet, editors, TAPSOFTT7: 
Theory and Practice of Software Development, 7th International Joint Confer- 
ence CAAP/FASE, Lille, France, Proceedings, LNCS Vol. 1214, pages 115-137. 
Springer, 1997. 

Describes a tentative design for Casl, motivating some of the design 
choices. 

Mosses : 1999 :CGT. 

Peter D. Mosses. Casl: A guided tour of its design. In J. L. Fiadeiro, editor. 
Recent Trends in Algebraic Development Techniques, 13th International Work- 
shop, WADT’98, Lisbon, Portugal, 1998, Selected Papers, LNCS Vol. 1589, 
pages 216-240. Springer, 1999. 

Indicates the major issues in the Casl design, explains and illustrates 
the main concepts and constructs. Based on a ^-day tutorial. 

Mosses : 2000 : CAS. 

Peter D. Mosses. Casl and Action Semantics. In P. D. Mosses and H. Moura, 
editors, AS 2000, Third International Workshop on Action Semantics, Recife, 
Brazil, Proceedings, BRICS NS-00-6, pages 62-78. Dept, of Computer Science, 
Univ. of Aarhus, 2000. 

Gives an overview of Casl, and considers pros and cons of using it 
as meta-notation in action semantic descriptions of programming lan- 
guages. 
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Mosses : 2000 : CCU. 

Peter D. Mosses. Casl for CafeOBJ users. In K. Futatsugi, A. T. Naka- 
gawa, and T. Tamai, editors, CAFE: An Industrial- Strength Algebraic Formal 
Method^ chapter 6, pages 121-144. Elsevier, 2000. 

Gives an overview of Casl, comparing it to CafeOBJ. 

Mosses : 2001 : CoFI. 

Peter D. Mosses. CoFI: The common framework initiative for algebraic speci- 
hcation and development. In G. Paun, G. Rozenberg, and A. Salomaa, editors. 
Current Trends in Theoretical Computer Science: Entering the 21st Century, 
pages 153-163. World Scientihc, 2001. 

Describes the aims, goals, and initial achievements of CoFI, extending 
and updating [Mosses: 1996: CoFI]. 

Reggio : 1999 :CLC. 

Gianna Reggio, Egidio Astesiano, and Christine Choppy. Casl-Ltl: A Casl 
extension for dynamic reactive systems - summary. Technical Report DISI-TR- 
99-34, Univ. of Genova, 1999. Revised August 2003, see [Reggio : 2003 : CLC]. 
Describes the Casl-Ltl extension language proposed for dynamic sys- 
tems specification, with dynamic sorts and temporal formulas. 

Reggio : 1999 :CFD. 

Gianna Reggio, Egidio Astesiano, Christine Choppy, and Heinrich Hussmann. 
A Casl formal dehnition of UML active classes and associated state machines. 
Technical Report DISI-TR-99-16, Univ. of Genova, 1999. A short version is 
published in [Reggio : 2000 : AUA] . 

Presents the labelled transition system associated with an active class 
using Case. 

Reggio: 1999 :MPU. 

Gianna Reggio, Egidio Astesiano, Christine Choppy, and Heinrich Hussmann. 
Making precise UML active classes modeled by state charts. Technical Report 
DISI-TR-99-14, Univ. of Genova, 1999. 

Presents the labelled transition system associated with an active class 
using Casl. 

Reggio : 2000 :ASU. 

Gianna Reggio, Maura Cerioli, and Egidio Astesiano. An algebraic semantics 
of UML supporting its multiview approach. In D. Heylen, A. Nijholt, and 
G. Scollo, editors. Algebraic Methods in Language Processing, AMiLP 2000, 
TWLT Vol. 16. Univ. of Twente, 2000. 

Using Casl as a metalanguage, proposes a semantics for class dia- 
grams, state machines and overall systems described using the UML. 

Reggio : 2000 : AUA. 

Gianna Reggio, Egidio Astesiano, Christine Choppy, and Heinrich Hussmann. 
Analysing UML active classes and associated state machines - A lightweight 
approach. In T. Maibaum, editor. Fundamental Approaches to Software Engi- 
neering, Third International Conference, EASE 2000, Berlin, Cermany, Pro- 
ceedings, LNCS Vol. 1783, pages 127-146. Springer, 2000. An extended version 
is provided in [Reggio : 1999 : CFD]. 

Presents the labelled transition system associated with an active class 
using Casl. 
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Reggio : 2000 : CCC. 

Gianna Reggio and Lorenzo Repetto. Casl-Chart: A combination of stat- 
echarts and of the algebraic specihcation language Casl. In T. Rus, editor, 
Algebraic Methodology and Software Technology, 8th International Conference, 
AM AST 2000, Iowa City, Iowa, USA, Proceedings, LNCS Vol. 1816, pages 
243-257. Springer, 2000. 

Presents a combination of statecharts and Casl. 

Reggio : 2000 : CCS. 

Gianna Reggio and Lorenzo Repetto. Casl-Chart: Syntax and semantics. 
Technical Report DISI-TR-00-1, Univ. of Genova, 2000. 

Presents the complete syntax and semantics of a combination of stat- 
echarts and Casl. 

Reggio : 2001 :RSU. 

Gianna Reggio, Maura Cerioli, and Egidio Astesiano. Towards a rigorous se- 
mantics of UML supporting its multiview approach. In H. Hussmann, editor. 
Fundamental Approaches to Software Engineering, fth International Confer- 
ence, EASE 2001, Cenova, Italy, Proceedings, LNCS Vol. 2029, pages 171-186. 
Springer, 2001. 

Using Casl as a metalanguage, proposes a semantics for class dia- 
grams, state machines and overall systems described using the UML. 

Reggio: 2003 :CLC. 

Gianna Reggio, Egidio Astesiano, and Christine Choppy. Casl-Ltl: A Casl 
extension for dynamic reactive systems - version 1.0 - summary. Technical Re- 
port DISI-TR-03-36, Univ. of Genova, 2003. A revision of [Reggio : 1999 :CLC]. 
Describes the Casl-Ltl extension language proposed for dynamic sys- 
tems specification, with dynamic sorts and temporal formulae. 

Roggenbach : 2000 : SRN. 

Markus Roggenbach, Lutz Schroder, and Till Mossakowski. Specifying real 
numbers in Casl. In D. Bert, C. Choppy, and P. D. Mosses, editors. Recent 
Trends in Algebraic Development Techniques, Ifth International Workshop, 
WADTT9, Chateau de Bonas, France, 1999, Selected Papers, LNCS Vol. 1827, 
pages 146-161. Springer, 2000. 

Presents a weak first-order theory of real numbers in Casl. 

Roggenbach: 2001 :TTS. 

Markus Roggenbach and Lutz Schroder. Towards trustworthy specihcations 
I: Consistency checks. In M. Cerioli and G. Reggio, editors. Recent Trends 
in Algebraic Development Techniques, 15th International Workshop, WADT 
2001, Joint with the CoFI WC Meeting, Cenova, Italy, 2001, Selected Papers, 
LNCS Vol. 2267, pages 305-327. Springer, 2001. 

Introduces a calculus for proving consistency of Casl specifications; 
the syntax-driven approach exploits in particular the Casl structuring 
operations 
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Roggenbach : 2003 : CCN. 

Markus Roggenbach. CSP-Casl - A new integration of process algebra and 
algebraic specihcation. In F. Spoto, G. Scoho, and A. Nijholt, editors, Algebraic 
Methods in Language Processing, AMiLP 2003, TWLT Vol. 21, pages 229-243. 
Univ. of Twente, 2003. 

Describes the integration of the process algebra CSP and the algebraic 
specification language Casl into one language, with denotational se- 
mantics in the process part and loose semantics for the datatypes. 

Roggenbach : 2004 : CASL-Libraries. 

Markus Roggenbach, Till Mossakowski, and Lutz Schroder. Casl libraries. In 
Casl Reference Manual, LNCS Vol. 2960 (IFIP Series), part V. Springer, 2004. 
Provides libraries of basic datatypes in Casl, including order-theoretic 
and basic algebraic concepts, simple and structured datatypes, and 
graphs. 

Salauen : 2002 : SAC. 

Gwen Salaiin, Michel Allemand, and Christian Attiogbe. Specihcation of an 
access control system with a formalism combining CCS and Casl. In Proc. of 
the 7th International Workshop on Formal Methods for Parallel Programming: 
Theory and Applications, FMPPTAT2, USA, 2002. IEEE Press. 

Advocates a formalism which combines the CCS process algebra with 
the Casl algebraic specification language, presents formal foundations 
of this combination, and illustrates it with a real size case study: an 
access control system to a set of buildings. 

Sannella : 2000 : ASP. 

Donald Sannella. Algebraic specihcation and program development by stepwise 
rehnement. In A. Bossi, editor, Logic-Based Program Synthesis and Transfor- 
mation, 9th International Workshop, LOPSTRT9, Venice, Italy, 1999 Selected 
Papers, LNCS Vol. 1817, pages 1-9. Springer, 2000. 

Provides an overview of formal algebraic notions of rehnement step. 

Sannella: 2000 : CoFI. 

Donald Sannella. The common framework initiative for algebraic specihcation 
and development of software. In D. Bjprner, M. Broy, and A. V. Zamulin, ed- 
itors, Perspectives of System Informatics, Third International Andrei Ershov 
Memorial Conference, PSP 99, Akademgorodok, Novosibirsk, Russia, Proceed- 
ings, LNCS Vol. 1755, pages 1-9. Springer, 2000. 

Gives an overview of CoFI, with emphasis on the features of Casl. 

Sannella: 2001 : CoFI-RP. 

Donald Sannella. The common framework initiative for algebraic specihcation 
and development of software: Recent progress. In M. Cerioli and G. Reggio, ed- 
itors, Recent Trends in Algebraic Development Techniques, 15th International 
Workshop, WADT 2001, Joint with the CoFI WC Meeting, Cenova, Italy, 
2001, Selected Papers, LNCS Vol. 2267, pages 328-343. Springer, 2001. 
Reports on progress with CoFI during 1998-2001. 
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Schroeder : 2001 : ACE. 

Lutz Schroder, Till Mossakowski, and Andrzej Tarlecki. Amalgamation in Casl 
via enriched signatures. In F. Orejas, P. G. Spirakis, and J. van Leeuwen, edi- 
tors, Automata, Languages and Programming, 28th International Colloquium, 
ICALP 2001, Crete, Creeee, Proeeedings, LNCS Vol. 2076, pages 993-1004. 
Springer, 2001. Extended version to appear in Theoretical Computer Science. 
Presents definition of and results about enriched Casl, which restores 
the lacking amalgamation property. 

Schroeder : 2001 : SAS. 

Lutz Schroder, Till Mossakowski, Andrzej Tarlecki, Piotr Hoffman, and Bartek 
Klin. Semantics of architectural specifications in Casl. In H. Hussmann, 
editor. Fundamental Approaehes to Software Engineering, fth International 
Conferenee, EASE 2001, Cenova, Italy, Proeeedings, LNCS Vol. 2029, pages 
253-268. Springer, 2001. Extended version to appear in Theoretical Computer 
Science. 

Solves the problems of Casl architectural specifications with subsorts 
by introducing enriched Casl and a diagram static semantics. 

Schroeder: 2002: HIS. 

Lutz Schroder and Till Mossakowski. HasCasl: Towards integrated specifica- 
tion and development of Haskell programs. In H. Kirchner and C. Ringeissen, 
editors. Algebraic Methods and Software Technology, 9th International Confer- 
ence, AMAST 2002, Saint-Cilles-les- Bains, Reunion Island, France, Proceed- 
ings, LNCS Vol. 2422, pages 99-116. Springer, 2002. 

The central paper explaining HasCASL, a higher-order extension of 
Casl including type constructors, polymorphism and recursion. 

Schroeder : 2003 : CCP. 

Lutz Schroder. Classifying categories for partial equational logic. In R. Blute 
and P. Selinger, editors. Category Theory and Computer Science, CTCS’02, 
ENTCS Vol. 69. Elsevier, 2003. 

Establishes correspondence results between partial equational theories, 
of which Casl signatures are a special case, and categories with certain 
finite limits, in preparation for the semantics of HasCasl. 

Schroeder: 2003 :HMP. 

Lutz Schroder. Henkin models of the partial A-calculus. In M. Baaz and 
J. M. Makowsky, editors. Computer Science Logic, 17th International Work- 
shop, CSL 2003, 12th Annual Conference of the EACSL, and 8th Kurt Cddel 
Colloquium, KCC 2003, Vienna, Austria, Proceedings, LNCS Vol. 2803, pages 
498-512. Springer, 2003. 

Shows that categorical models of the partial lambda-calculus and in- 
tensional Henkin models, as used in the semantics of HasCasl, are 
equivalent 
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Schroeder : 2003 : MID. 

Lutz Schroder and Till Mossakowski. Monad-independent dynamic logic in 
HasCasl. In M. Wirsing, D. Pattinson, and R. Hennicker, editors, Recent 
Trends in Algebraic Development Techniques, 16th International Workshop, 
WADT 2002, Frauenchiemsee, Germany, 2002, Revised Selected Papers, LNCS 
Vol. 2755, pages 425-441. Springer, 2003. Extended version to appear in Jour- 
nal of Logic and Computation. 

Monad-independent dynamic logic in the framework of HasCasl; ad- 
mits reasoning about termination and total correctness. 

Schroeder: 2003 :MIH. 

Lutz Schroder and Till Mossakowski. Monad-independent Hoare logic in Has- 
Casl. In M. Pezze, editor. Fundamental Approaches to Software Engineer- 
ing, 6th International Conference, EASE 2003, Warsaw, Poland, Proceedings, 
LNCS Vol. 2621, pages 261-277. Springer, 2003. 

Hoare logic for arbitrary monads (e.g., exceptions, non-determinism, 
references, input/output) in the framework of HasCasl. 

Schroeder : 2004 : ASC. 

Lutz Schroder, Till Mossakowski, Andrzej Tarlecki, Bartek Klin, and Piotr 
Hoffman. Amalgamation in the semantics of Casl. Theoretical Computer 
Science. To appear; extends [Schroeder : 2001 :SAS, Schroeder : 2001 : ACE]. 
Solves the problems of Casl architectural specifications with subsorts 
by introducing enriched Casl and a diagram static semantics. 

Schroeder : 2004 : MID. 

Lutz Schroder and Till Mossakowski. Monad-independent dynamic logic 
in HasCasl. Journal of Logic and Computation. To appear; extends 

[Schroeder: 2003: MID]. 

Monad-independent dynamic logic in the framework of HasCasl; ad- 
mits reasoning about termination, partial and total correctness. 

Tarlecki: 2003: AST. 

Andrzej Tarlecki. Abstract specification theory: An overview. In M. Pizka and 
M. Broy, editors. Models, Algebras and Logic of Engineering Software, NATO 
Science Series: Computer & Systems Sciences Vol. 191, pages 43-79. lOS Press, 
2003. 

Provides an overall view of abstract specification and software devel- 
opment theory, including a version of Casl architectural specifications 
with an example, semantics and verification rules. 
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graph 1V:350 

(p,Ei, . . . , En^E) based signature of 
generic unit with import 111:249 
(p, E^E) based signature of generic 
unit with import 111:249 
(p, UE) based signature of generic unit 
with import 111:249 
(Ps, Bs, D) extended static unit context 
111:249 

(Ps, Bs,D) + (P's, B's,D') addition of 
extended static unit contexts 
111:249 

(S' , F') sort-generation constraint 1:8, 
111:134 

(S',F',a) sort-generation constraint 
111:134 

(S, TF,PF,P) 

many-sorted signature extension 
111:125 

many-sorted signature fragment 
111:125 

many-sorted signature 1:6,111:124 
(S, TF, PF, P) U (S', TF', PF', P') 
union of many-sorted signature 
fragments 111:125 
(S, TF,PF,P,<) 

subsorted signature extension 
111:170 

subsorted signature fragment 

111:170 

subsorted signature 1:27, 111:169 
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(S, TF, PF, P, <)U(P', TP', PP', P', <0 
union of subsorted signature frag- 
ments 111:170 

many-sorted model 

111:128 

(le, s) function profile 1:6, 111:124 
{xl ^ , . . . , } sorted variable set 

IILlsf 

negation formula 111:133 
||P|| symbols in a signature 111:192 
||cr|| symbol map induced by a signature 
morphism 111:195 

1^1 

signature symbols in a many-sorted 
signature 111:126 

signature symbols in a signature 1:5 
signature symbols in a subsorted 
signature 111:171 

\E\ signature symbols in a subsorted 
signature 111:191 

kl 

function on signature symbols arising 
from a many-sorted signature 
morphism 111:128 
function on signature symbols 

arising from a subsorted signature 
morphism 111:171, 191 
\A\ cardinality of a set A 111:116 
\ASP\ architectural specification 
without axioms IV:338 
\C\ class of objects in a category 
111:117 

\w\ length of a sequence 111:116 
< subsort embedding 1:27,111:169 
(ai, . . . , an) sequence 111:116 
(Ml, . . . , Mn) compatible models 

111:229 

(si, . . . , Sn)^ product of carrier sets 

111:129 

= token for a language with equality 
1:62 

3\X.(^ unique-existential quantification 
111:133 

existential quantification 111:133 
\/xs.(f universal quantification 111:132 
I^lp value of a term in a many-sorted 
model with respect to an 
assignment 111:136 



□ dummy denotation in extended static 
semantics IV:335 
hi: ent ailment relation 291 
^ satisfaction relation of an institution 
5, 123 

0 

empty semantic object 111:117 
empty signature 111:193 
P context IV:334, 348 
F[B' /B] substitution of unit names in 
context IV:334 

Fgen gcncric context IV :334, 348 
Fs,Fm • SPEC ^ P semantic con- 
sequence of a specification 
326 

Fs,Fm • SPECi?^SPEC 2 refinement 
between specifications IV:326 
Fs : SPEC h P provability from a 
specification 326 

Fs : SPECi ^ SPEC 2 refinement proof 
IV:327 
zA 

many-sorted signature extension 
111:125 

subsorted signature extension 
111:170 
zAUzA' 

union of many-sorted signature 
extensions 111:125 
union of subsorted signature 
extensions 111:170 

Fm model global environment 111:266 
Fs static global environment 111:266 
r;(7?(SPEC)) Ui^i. ,n »?ZS(SPECi)) 

refinement between translated 
specifications IV:328 
injection 111:193 
1/ \ Z removing variables from 
substitution IV:280 
u: X — >Te{Y) substitution IV:279 
p assignment 111:135 
p : X ^ M assignment 111:135 
p[xs ^ a] augmented assignment 
111:135 
V 

many-sorted signature 1:6,111:124 
signature in an institution 1:5 
subsorted signature 1:27, 111:169 
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a 

many-sorted signature morphism 
1:7, 111:126 

signature morphism in an institution 
1:6 

subsorted signature morphism 1:28, 
111:171 
a'{S\F\a) 

translation of a constraint along a 
many-sorted signature morphism 
111:134 

translation of a constraint along a 
subsorted signature morphism 
111:174 

Ui, . . . , generic unit signature 

111:228 
E' 

many-sorted signature inclusion 
111:127 

subsorted signature inclusion 
111:171 

E^E generic unit signature 111:228 
cr{A) extension of cr along A 111:199 
a{(p) 

translation of a formula along a 
many-sorted signature morphism 
111:134 

translation of a formula along a 
subsorted signature morphism 
111:174 

E* many-sorted signature associated 
with a subsorted signature 1:28, 
111:172 

cr^ many-sorted signature morphism 
associated with a subsorted 
signature morphism 1:28,111:172 
Ea(A) extension of Ea along A 
111:199 

E^ signature of a node IV:293 
predicate symbol map 111:126 
partial function symbol map 
111:126 

cr^ sort map 111:126 

total function symbol map 111:126 

ruzA 

union of a many-sorted signature and 
a many-sorted signature extension 
111:125 



union of a subsorted signature and 
a subsorted signature extension 
111:170 
E\JE' 

union of many-sorted signatures 
111:125 

union of subsorted signatures 
111:170, 193 

gigj^ature co-generated in a 
signature by a set of signature 
symbols 198 

signature generated in a 
signature by a set of signature 
symbols 197 
if formula 111:131 
^ t\t' conditional term 111:131 
Lp Lp' equivalence formula 111:133 
(p ^ (p' implication formula 111:132 
(p[u] application of substitution to 
formula IV: 280 

(p A (p' conjunction formula 111:133 
(p\/ ip' disjunction formula 111:133 
^ \- (p ent ailment 281 

\=E semantic consequence 283 
^ set of sentences 111:135 
'ip sentence 111:134 

local axioms of a node IV: 293 

A alternative construct 1:15 
Ai X • • • X An Cartesian product 

111:116 

A ^ 5 set of finite maps from A to B. 

111:116 

A ^ B set of partial functions from A 
to B 111:116 

A ^ B set of total functions from A to 
B 111:116 

AE architectural signature 111:228 
A : E unit name A has signature E 
IV:348 

A[B' / B] substitution of one unit name 
for another IV:334 
AM architectural model 111:230 
AM architectural specification 111:230 
aquaC injection into a union of syntactic 
categories 111:117 
ArchMod(Cs, W) domain of archi- 
tectural models over a static 
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unit context and a unit signature 
111:230 

ArchSig domain of architectural 
signatures 111:228 
ArchSpec domain of architectural 
specifications 111:230 
ArchSpec(Ai7) domain of archi- 
tectural specifications over an 
architectural signature 111:230 
ArchSpecN ame domain of architectural 
specification names 111:228 
ASN architectural specification name 
1:51,111:228 

ASP architectural specification 1:51 
Assignment domain of assignments 
111:135 

Atom atomic logic axioms 1:62 
A\S B disjoint union 111:117 
A U 5 union 111:116 
Ax{T) axioms of a theory IV:291 

BasedParUnitSig domain of based 
signatures of generic units with 
import 111:249 
BI basic item 1:9 
Bs static based unit context 111:249 

C 

constructor component 1:15 
token for a language with sort 
generation constraints 1:62 
unit context 111:231 
empty unit context 111:231 
Cs empty extended static unit context 
111:249 

Cg empty static context 111:229 
C[UN jU] extension of unit context by 
unit declaration 111:231 
C[UN / UEv] extension of unit context 
by unit definition 111:231 
Carrier domain of carriers 111:128 
Carriers domain of sort-indexed 
families of carriers 111:128 
CAT quasicategory of categories 
111:117 

complete{f, S) completion of a function 
to a larger domain 111:117 



CompMod(Z'i, . . . , Bn) domain 
of compatible models over 
Bi,...,Bn 111:229 

Cond positive conditional logic axioms 
without predicates 1:62 
Constraint domain of sort-generation 
constraints 111:134 
context h phrase ^ result model 
semantics judgement 119 
context h phrase result verification 

semantics judgement 317 
context h phrase result extended 

static semantics judgement 251 
context h phrase > result static 
semantics judgement 119 
Cs extended static unit context 111:249 
Cs static unit context 111:228 
ctx{Ps, Bs, D) static unit context in 
an extended static unit context 
111:249 

D signature diagram 111:248 
DD datatype declaration 1:14 
T>G = (A/*, C) development graph 
IV:293 

dgm{Ps, Bs, D) diagram of an extended 
static unit context 111:249 
VQ h L derivation relation for 
development graphs 298 
Diag domain of signature diagrams 
111:248 

dom(T) domain of a context IV:334 
Dom{Cs) domain of an extended static 
unit context 111:249 
Dom{f) domain of a function 111:116 
D{t) definedness formula 111:133 

E unit environment 111:230 
e edge in a diagram 111:248 
Edges (D) set of edges of Shape{D) 
111:248 

Empty Explicit {B^^ ^ SSY) forget 

signature symbols component 
111:201 

Enrichment domain of many-sorted 
enrichments 111:135 
Eq atomic logic axioms without 
predicates 1:62 
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Extension domain of many-sorted 
signature extensions 111:125 
Ext{h) extension of symbol map along 
a generic specification 111:224 
ExtlD(h) extension of identifier map 
along a generic specification 
111:224 

Ext{r) extension of a symbol map 

111:196 

F 

formula 1:19 
generic unit 111:229 
/ function name 1:7, 111:124 
F 0 M' amalgamation of a generic unit 
and a compatible model 111:229 
fog composition of morphisms 111:117 
FA fitting argument 1:42 
false falsity 111:132 
FAU fitting argument unit 1:56 
FI file identifier 1:60 
FinSeq{A) set of finite sequences of 
elements from A 111:116 
FinSet{A) set of finite subsets of A 
111:116 

F^ function symbol-indexed family of 
functions 111:128 
FM fitting morphism 1:43 

function symbol interpretation 
1:7, 111:128 

Fws (/) function symbol interpretation 
111:128 

FOAlg first-order logic axioms without 
predicates 1:62 

FOL first-order logic axioms 1:62 
Formula domain of formulas 111:131 
f^s qualified partial function symbol 
111:191 

FQTerm domain of fully- qualified terms 
111:131 

fl^s qualified total function symbol 
111:191 

FunName universe of function symbols 
111:124, 142, 172 

FunProfile domain of function profiles 
111:124 

FunSet domain of function symbol sets 
111:124 



FV {(f) free variables of a formula 
111:133 

FV (t) free variables of a term 111:133 
fws qualified function symbol 111:126 
fws{ti, ... An) term formed by function 
application 111:131 
fws fws' overloading relation on 

qualified operation symbols 1:27, 
111:171 

f{x) function application 111:116 
fx xth item in an indexed family 
111:116 

GCond generalized positive conditional 
logic axioms without predicates 
1:62 

GD global directory 111:268 
GenSig domain of generic signatures 
111:202 

GenSpec domain of semantic objects 
underlying generic specification 
111:203 

GHorn generalized positive conditional 
logic axioms 1:62 

GlobalDir domain of global directories 
111:268 

graph{f) graph of a function 111:116 
GSm model semantics for a generic 
specification 111:203 
GSm{{Mt, cri), . . . , {Mn, cTn)) appli- 
cation of model semantics for a 
generic specification to fitting 
arguments 111:203 
GSs generic signature 111:202 
GSs{{Ff,ai ), . . . , applica- 

tion of generic signature to fitting 
arguments 111:202 

h 

many-sorted homomorphism 1:7, 
111:129 

signature symbol map 111:195 
Homomorphism domain of many- 
sorted homomorphisms 111:129 
Horn positive conditional logic axioms 
1:62 
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h\u 

reduct of a homomorphism with 
respect to a many-sorted signature 
inclusion 130 

reduct of a homomorphism with 
respect to a signature inclusion 
194 

h\a 

reduct of a homomorphism with 
respect to a many-sorted signature 
morphism 130 

reduct of a subsorted homomorphism 
with respect to a signature 
morphism 174 

I identifier 1:46 

id A identity morphism on A 111:117 
IDAsSym{Ident) identifier as a symbol 

111:192 

ImpUnitSig domain of signatures of 

generic units with import 111:228 
IN item name 1:59, 111:266 
ItemName domain of item names 
111:266 

k kind of symbol 111:191 
ker{f) kernel of a function 111:116 

C set of links in a development graph 
IV:293 
LI 

library identifier 111:267 
library item 1:58 
Libid domain of library identifiers 
111:267 

LibName domain of library names 
111:267 

LN library name 1:58, 111:267 
M 

many-sorted model 1:7, 111:128 
subsorted model 111:173 
unit 111:229 
M 

class of many-sorted models 111:128 
class of models in an institution 
1:38, 111:202 

Ml 0 ... 0 Mn amalgamation of 
compatible models 111:229 



M = M' isomorphism 111:131 
M±_ class of models over the empty 
signature 111:193 
M compatible models 111:229 
matches matching relation between 
signature symbols and symbol 
111:192 

MEv model evaluator 111:230 

Mod 

model functor in many-sorted 
institution 111:130 

model functor of an institution 
111:123 
Mod(r) 

category of i7-models of an institution 
1:5,111:123 

category of many-sorted i7-models 

1:7, 111:129 
Mod(cr) 

translation of models in an institution 
1:6, 111:123 

Mod^(i7) partial model functor 
IV:339 

Mod(D) class of all Nodes {D)-mde:s.ed 
model families consistent with D 
111:249 

’M.od'Dg(N) model class of a node in a 
development graph IV: 294 
Model domain of many-sorted models 
111:128 

ModelClass domain of classes of 
many- sort ed mo dels 111:128 
ModEval domain of model evaluators 
111:230 

ModEval(V) domain of model 
evaluators over a signature 
111:230 

M \= satisfaction of a 

sort-generation constraint 137 

M \=p (f 

satisfaction of a formula by a 
many-sorted model under an 
assignment 136 

satisfaction of a formula by a sub- 
sorted model under an assignment 
175 

M ^ ^ 

satisfaction of a sentence by a 
many-sorted model 137 
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satisfaction of a sentence by a 
subsorted model 175 

M\jj 

reduct of a model with respect to a 
many-sorted signature inclusion 
130 

reduct of a model with respect to a 
signature inclusion 194 

M|, 

reduct of a model with respect to 
many-sorted signature morphism 
130 

reduct of a subsorted model with 
respect to a signature morphism 
174 

N version number 1:59 
JV set of nodes in development graph 
IV:293 

N ^ ^ local implication IV: 295 
name{SSY) name of a signature symbol 

111:192 

Nodes (D) set of objects of Shape{D) 
111:248 

O — — ^ N local theorem link IV: 295 

O — N local definition link 
IV:293 

O = = ^ N global theorem link 
IV:295 

O N global reachability IV: 293 

O > N global definition link 
IV:293 

O ^ N conservative extension 

cons 

(definition link) IV:297 
O = = ^ N conservative extension 

cons 

(theorem link) IV: 296 
O ^ )> N definitional extension 

def 

(definition link) IV:297 
O = = ^ N definitional extension 

def 

(theorem link) IV: 296 
O > N free definition link IV: 293 

free 

O = = ^ N free theorem link IV: 295 

free 9 



O > N hiding definition link 

hide 

IV:293 

O = = ^ V hiding theorem link 

hide 9 

IV:295 

0 N monomorphic extension 
(definition link) IV:297 

Q TV monomorphic extension 

(theorem link) IV:296 

0>=^^ N local reachability IV: 294 

01 operation item 1:11 
OS operation symbol 1:23 

P 

set of predicate symbols 111:124 
token for a language with partiality 
1:62 
P 

node in a diagram 111:248 
path 111:267 

predicate name 1:7,111:124 
V{UT) set of generic unit names not 
used IV:341 

PartialFun domain of function symbol 
interpretations 111:128 
PartialFuns domain of function 
symbol-indexed families of 
functions 111:128 
ParUnitSig domain of generic unit 
signatures 111:228 
Path domain of paths 111:267 
PF set of partial function symbols 
111:124 

PFMap domain of partial function 
symbol maps 111:126 
PFws set of partial function symbols 
with profile ws 1:6,111:124 
PI predicate item 1:13 
P^ predicate symbol-indexed family of 
predicates 111:128 
predicate symbol interpretation 
1:7, 111:128 

PMap domain of predicate symbol maps 
111:126 

Pw ip) predicate symbol interpretation 
111:128 

Pred domain of predicate symbol 
interpretations 111:128 
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PredName universe of predicate symbols 
111:124, 146, 172 

PredProflle domain of predicate profiles 
111:124 

Preds domain of predicate symbol- 
indexed families of predicates 
111:128 

PredSet domain of predicate sets 

111:124 

Pres category of presentations IV:291 
Ps based static context for generic units 
111:249 

PS predicate symbol 1:21 
V{UT) set of generic unit names used 
IV:341 

Pw set of predicate symbols with profile 
w 1:6,111:124 

Pw qualified predicate symbol 111:126, 
191 

. . . , tn) formula formed by 
predicate application 111:132 
Pw Pw' overloading relation on 

qualified predicate symbols 1:27, 
111:171 

q node in a diagram 111:248 
QualFunName domain of qualified 
function symbols 111:126 
QualPredName domain of qualified 
predicate symbols 111:126 
QualVarName domain of qualified 
variable names 111:131 

R 

renaming 1:55 
restriction 1:55 
r symbol map 111:195 
R = (#, a, P) institution comorphism 
_ IV:291 

R{SP) specification augmented by 
translation axioms IV:349 
R{VQ) translation of a development 
graph along a comorphism 
IV:297 

r\^ induced signature morphism 198 
r\%, induced signature morphism 199 

S set of sorts 1:6, 111:124 
s sort name 111:124, 191 



Sen 

sentence functor in many-sorted 
institution 111:135 

sentence functor of an institution 
111:123 
Sen(r) 

set of i7-sentences of an institution 
1:5,111:123 

set of many-sorted Z'-sentences 1:8, 
111:132 
Sen(cr) 

translation of sentences in an 
institution 1:6,111:123 
Sentence domain of sentences 111:134 
Set category of sets 111:117 
Set (A) set of all subsets of A 111:116 
Shape{D) shape category of a signature 
diagram 111:248 
SI 

signature item 1:17 

sort item 1:10 
Sig 

category of many-sorted signatures 

111:128 

category of signatures of an 
institution 1:5,111:123 
SigFragment domain of many-sorted 
signature fragments 111:125 
Signature domain of many-sorted 
signatures 111:124 
SignatureMorphism domain of many- 
sorted signature morphisms 
111:126 

SigSym domain of signature symbols 

111:126 

SigSymMap domain of signature symbol 
maps 111:195 

Sig(T) signature of a theory IV: 291 
SL symbol list 1:37 

sort-indexed family of carriers 
111:128 

SM symbol mapping 1:37 

carrier set (sort interpretation) 

1:7, 111:128 

SMap domain of sort maps 111:126 
(s) carrier set (sort interpretation) 
111:128 

SN specification name 1:41 
Sort universe of sorts 111:124, 141 
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SortRelation domain of subsort 
embeddings 111:169 
Sorts et domain of sort sets 111:124 
SP specification 1:37 
StBasedUnitCtx domain of static based 
unit contexts 111:249 
ExtStUnitCtx domain of extended static 
unit contexts 111:249 
StParUnitCtx domain of based static 
contexts for generic units 111:249 
strip(GSs) stripping down a verification 
generic signature to a generic 
signature IV:315 

strip(Vs) stripping down a verification 
view signature to a view signature 
IV:316 

StUnitCtx domain of static unit 
contexts 111:228 

Suh token for a language with subsorting 
1:62 

SubMod model functor in subsorted 
institution 111:174, 191 
SubMod(i7) category of subsorted 
i7-models 111:174 

SubSen sentence functor in subsorted 
institution 111:174, 191 
SubSen(Z') set of subsorted E- 
sentences 111:174 

SubSig domain of subsorted signatures 

111:169 

SubSig category of subsorted 
signatures 111:171, 191 
Suh sort edExtension domain of subsorted 
signature extensions 111:170 
SuhsortedSigEragment domain of 
subsorted signature fragments 
111:170 

SY symbol 1:40,111:191 
Sym domain of symbols 111:191 
SymAsSigSym{SY) symbol as a 
signature symbol 111:192 
SymKind domain of symbol kinds 
111:191 

SymMap domain of symbol maps 
111:195 

T term 1:23 

t fully-qualified term 111:131 
t = t' existential equation 111:132 



t = t' strong equation 111:133 
t[i>] application of substitution to term 
IV:280 

TE set of total function symbols 
111:124 

TEMap domain of total function symbol 
maps 111:126 

TEws set of total function symbols with 
profile 1:6,111:124 
Th category of theories IV:291 
Th'Dg(N) theory of a node in a 
development graph IV:294 
true truth 111:133 
TY operation type 1:11 

U unit 111:229 
U unit specification 111:230 
u URL 111:267 

14 0 MEv import extension of a unit 

specification by a model evaluator 
111:230 

UE unit signature 111:228 
UD unit declaration or definition 1:51 
UE unit expression 1:51 
UEv unit evaluator 111:230 
Um model universal environment 
111:267 

UN unit name 1:52, 111:228 
Unit domain of units 111:229 
unit singleton set 111:116 
Unit(U) domain of units over a 
signature 111:229 
Unit(Ui, . . . , En^E) domain of 

generic units over a generic unit 
signature 111:229 
Unit^(U ^ E') set of partial unit 
functions IV:339 
UnitCtx domain of unit contexts 
111:231 

UnitEnv domain of unit environments 
111:230 

UnitEnv(Cs) domain of unit environ- 
ments over an extended static 
context 111:250 

UnitEnv (Us) domain of unit environ- 
ments over a static unit context 
111:230 

UnitEval domain of unit evaluators 
111:230 
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UnitEval(t/i7) domain of unit eval- 
uators over a unit signature 
111:230 

UnitName domain of unit names 
111:228 

UnitSig domain of unit signatures 
111:228 

Unit Spec domain of unit specifications 
111:230 

UnitSpecName domain of unit 
specification names 111:228 

Unit S pec (t/Z') domain of unit spec- 
ifications over a unit signature 
111:230 

UnivEnVm domain of model universal 
environments 111:267 

UnivEnVs domain of static universal 
environments 111:267 

Url domain of URLs 111:267 

Us static universal environment 
111:267 

USN unit specification name 111:228 

USE unit specification 1:52 

V 

variable 1:23 
version 111:267 

Var universe of variable names 111:131 

Variables domain of sorted variable sets 

111:131 

VD variable declaration 1:17 



VerArchSig verification architectural 
signatures IV:358 

VerGenSig verification generic signature 
IV:312 

Version domain of versions 111:267 
Ver UnitSig verification unit signatures 
IV:358 

VerViewSig verification view signature 
IV:316 

ViewSig domain of static semantic 

objects underlying views 111:203 
ViewSpec domain of model semantic 
objects underlying views 111:203 
Vm model semantics of a view 111:203 
VN view name 1:43 
Vs static denotation of a view 111:203 

W map from constructors to sets of 
partial selectors 111:148 
w predicate profile 1:6, 111:124 
product of carrier sets 1:7 
ws function profile 111:124 

X sorted variable set 1:7, 111:131 
X variable 111:131 

X + {xs} extending a sorted variable 
set with overriding 111:131 
X -\- X' combining sorted variable sets 
with overriding 111:131 
Xs qualified variable name 111:131 
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±-Z'-model IV:339 
±-unit family consistent with Fgen 
IV:341 

cj-complete partial order V:368 
cj-cpo V:368 
n-colorable graph V:373 

abbreviated 

annotation 11:103 
comment 11:103 
grammar 11:81 
Abelian group V:369 
abstract syntax 

relationship to concrete syntax 11:73 
abstract syntax 11:73, 75 
accidental inconsistency 111:181 
action 

group V:374 
monoid V:374 
addition 

admissible 111:249 
compatible 111:250 
admissible addition 111:249 
admit weak amalgamation 1V:291 
algebra 

free V:377 
linear V:375, 377 
many-sorted partial 1:7 
over a field V:377 
algebra V:369, 374 
alternative 

sequence 11:87 
subsort 1:30 



alternative 1:15, 30, 111:150, 177 
amalgamability, ensures 111:250, 
1V:334 

amalgamate 1:50 
amalgamation 

of compatible models 111:229 
unit 1:55, 111:244 
amalgamation 1:55, 111:259 
ambiguity 

architectural specification 11:94 
formula 11:94 

structured specification 11:94 
term 11:94 
ambiguity 1:24, 11:93 
analysis 

lexical 11:88, 97 
mixfix grouping 11:88, 93, 95 
annotation 

abbreviated 11:103 

associativity 11:107 

authors 11:111 

bracket 11:103 

conflicting 11:105 

conservative extension 1:39, 11:110 

date 11:111 

definitional extension 1:39,11:111 

display 1:25,11:106 

extension 11:110 

global 11:105 

grouping 11:103 

HTML 11:106 

implicit associativity 11:108 

implied axiom 11:110 
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implied extension 1:39,11:111 
label 11:106 
I^TeX 11:106 
list 11:109 
literal syntax 11:108 
local associativity 11:108 
mixfix display 11:106 
monomorphic extension 1:39,11:111 
non-nested 11:103 
number 11:108 
parsing 11:106 
precedence 11:107 
preceding 11:104 
RTF 11:106 
semantic 11:110,111:208 
single-line 11:105 
string 11:109 
trailing 11:104 
annotation 11:103, 105 
application 

operation 1:23,111:166 
predicate 1:8,21,111:163 
unit 1:56, 111:245, 260 
applicative semantics 111:262, IV:338 
architectural 

basic specification 1:51, 111:233, 252 
concept 1:49 
model 111:230 
signature 111:228 

specification definition 1:51, 111:232, 
251 

specification model 1:50 
specification name 1:51 
specification reference 1:51 
specification 1:49, 50, 111:227, 232 
unit specification 1:53, 111:239 
argument 

fitting list 1:42 
fitting morphism 1:42 
fitting specification 1:42 
fitting view 1:45 
fitting 1:56, 111:245 
sort 1:6,111:124 
specification 1:34 
unit 111:245 
arguments 

compatible fitting morphisms 1:42 
compatible 1:50 
array V:371 



ASCII 11:97 
assertion, definedness 1:8 
assignment 111:135 
associated element V:370, 375 
associativity 

annotation 11:107 
attribute 1:12,11:108 
implicit annotation 11:108 
local annotation 11:108 
associativity 111:143 
assumed property 1:49 
atomic 

formula 1:8,21,31,111:184 
logic 1:67 

atomic formula 111:162 
attribute 

associativity 1:12,11:108 
commutativity 1:12 
idempotency 1:12 
operation 1:12,111:143 
unit 1:12 

authors annotation 11:111 
auxiliary symbol 1:36 
axiom 

implied annotation 11:110 
list 1:18 
of choice V:377 
axiom 1:5, 18,31,111:159, 184 

bag V:371, 374 
base V:375, 377 
basic 

algebraic structure V:369 
architectural specification 1:51, 
111:233, 252 
datatypes V :363 
item 1:9 

many-sorted specification 1:9, 
111:138 

specification concept 1:5 
specification framework 1:5 
specification semantics 1:6 
specification 1:5,111:123 
subsorted specification 1:27,111:175 
binary tree V:372 
bipartite graph V:373 
body, specification 1:34, 41 
braces, grouping 1:36 
bracket 
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annotation 11:103 
comment 11:103 
branching structure V:372 

calculus, proof IV:275 
carrier 

non-empty 111:128 
set 1:7,111:128 
Casl 

extension 1:68 

institution with qualified symbols 
111:190 

institution with symbols 111:191 
sublanguage 1:61 
sublanguages 1:62 
Casl-Ltl extension 1:68 
cast, term 1:32,111:187 
category theory 111:117 
CATS V:364 
character 

quoted token 11:100 
representation V:370 
set 11:97 
character V:370 
closed 

specification 1:34, 36, 40, 111:210 
subsignature 111:197 
unit specification 1:53, 111:239 
coalgebraic extension 1:68 
CoCasl extension 1:68 
cocone, weakly amalgamable IV: 291, 
349 

cogenerated signature 111:198 
comment 

abbreviated 11:103 
bracket 11:103 
formatting 11:104 
grouping 11:103 
HTML 11:105 
IATeX 11:105 
multi-line 11:104 
non- nested 11:103 
RTF 11:105 
single-line 11:104 
comment 11:103 
commenting- out 11:104 
commutative monoid V:374 
commutativity 
attribute 1:12 



commutativity 111:143 
comorphism 

condition IV: 292, 349 
institution IV:291 
compactness IV:285 
compatibility 

of global environments 111:232 
unit term 1:55 

with extended static context 111:250 
compatible 

addition to unit context 111:231 
additions 111:250 
arguments 1:50 

extension of unit context 111:231 
extensions 111:250 
fitting argument morphisms 1:42 
fitting morphism 111:214 
global environments 111:266 
models 111:229 
signature morphisms 111:195 
static and model global environments 
111:204 

unit context 111:231 
unit 111:229 

universal environments 111:268 
complete 

lattice V:368 
partial order V:368 
complete IV: 283 
completeness 

for the extended static semantics 
IV:338 

of calculus for basic specifications 
IV:284 

of extended static analysis 111:262 
of rules for development graphs 
IV:308 

completeness IV:277, 310, 353 
completion function 111:117 
component 

constructor 1:16 
sort 1:16 
syntactic 11:75 
composition 
model 1:49 
morphism 111:117 
unit 1:54, 111:227 
compound 

identifier translation 1:47 
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identifier 1:47, 11:96, 111:223 
concept 

architectural 1:49 
basic specification 1:5 
library 1:57 
structuring 1:33 
subsorting 1:27 
concrete syntax 

relationship to abstract syntax 11:73 
concrete syntax 11:73, 87 
conditional 

generalized positive logic 1:66 
positive logic 1:65 
term 1:24,111:168 
conflicting annotation 11:105 
congruence IV: 280 
conjunction 1:20 
connected graph V:373 
connectedness V:375 
connective, logical 1:19, 111:160 
consequence 1:6 
conservative 

extension annotation 1:39,11:110 
extension 111:209, IV:296 
conservativity IV:310 
consistency IV:297, 310 
consistent with F 

model family IV:353 
unit family IV:353 
consistent 1:6, 111:249 
constant 

qualified 1:24 
constant 1:6,111:124,165 
constraint 

sort-generation 1:8, 9 
translation 111:134 
constraint 1:6 
Construct... V:370 
construction, pushout 1:35 
constructor 

component 1:16 
partial 1:15 
syntactic 11:75 
total 1:15 
context 

generic IV:334, 348 
static IV:330 
unit 111:231 
context-free 



grammar meta-notation 11:87 
grammar 11:75, 87 
parsing 11:88 
context IV:330, 334, 348 
cpo V:368 

Craig interpolation property IV: 289 
Csp-Casl extension 1:69 
current signature 1:34, 111:204 

data structure V:371 
datatype 

declaration 1:15, 30, 111:149 
free declaration 1:16, 30, 39, 111:152, 
178 

generated declaration 1:17 
structured V:370 
datatype 1:14, 30, 111:147 
datatypes, basic V:363 
date annotation 11:111 
decimal 

fraction 11:108, V:368 
notation 11:108, V:366 
declaration 

datatype 1:15, 30, 111:149 
free datatype 1:16, 30, 39, 111:152, 
178 

generated datatype 1:17 
global variable 1:17, 111:158 
isomorphism 1:29, 111:176 
local variable 1:18,111:158 
operation 1:11,111:142 
partial selector 1:16 
predicate 1:13,111:146 
repeated 1:10 
signature 1:10,29,111:140 
sort 1:10, 11,111:141 
subsort 1:29, 111:176 
total selector 1:16 
unit 1:51,52,111:235,253 
variable scope 1:18 
variable 1:18 
decomposition, task 1:49 
deduction, natural IV:277 
definedness 
assertion 1:8 
formula 1:22,111:164 
definedness 1:22 
definition 
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architectural specification 1:51, 
111:232, 251 

generic specification 1:41 
library 1:58 
link IV:293 

named specification 1:41 
operation 1:13,111:144 
partial operation 1:13 
predicate 1:14, 111:147 
specification 1:40, 111:211, 266 
subsort 1:29,111:176 
total operation 1:13 
unit specification 1:52, 111:237 
unit 1:51, 52,111:236, 254 
view 1:43, 111:216 
definitional extension 
annotation 1:39, 11:111 
definitional extension 111:209, IV:296 
degree function V:374 
dependencies between units 111:248 
dependencies, diagram 111:249 
derivation 
rule IV:280 
derivation IV: 281 
derived grammar 11:95 
determinant V:375 
development graph IV:275, 289, 293 
diagram 

extension 111:248 
of dependencies 111:249 
signature 111:248 
direct link 1:59 
directed graph V:372 
directory, global 1:57, 111:267, 268 
disambiguated 1:46 
disambiguation 11:93 
disjoint union 1:30,111:117 
disjoint ly extends 111:248 
disjunction 1:20 
display 

annotation 1:25, 11:106 
format 11:97, 98 
mixfix annotation 11:106 
distributed library 1:58 
divisibility V:370 
division with remainder V:375 
domain, semantic 111:118 
downloading 1:58, 59, 111:267 



Eigenvariable condition IV: 282 
elided rule 111:120 
elimination oracle for free definition 
links IV:309 
embedding 
explicit 1:32 
implicit 1:32 
operation 1:28 
subsort 1:27,48,111:169 
symbol 111:172 
embedding 1:27 
empty 

signature 111:193 
specification 1:9 

encoding of the Casl logic IV:285 
enrich 1:36 
enriched Casl IV: 292 
enrichment 

subsorted 111:175 
enrichment 111:135 
ensures amalgamability 111:250, 
IV:334 

ent ailment system IV:285, 290 
entity, syntactic kind 11:75 
enumeration type 1:17 
environment 

global, compatible static and model 
111:204 

global 1:34, 51, 57, 58, 111:204, 266 
local 1:6,34,58,111:138,204 
model global 111:266 
static global 111:266 
static universal 111:267 
unit 111:230 
universal model 111:267 
environment IV :330 
environments 

compatible global 111:266 
compatible universal 111:268 
equality feature 1:65 
equation 

existential 1:8, 22, 111:164 
strong 1:8, 22, 111:164 
equation 1:22 
equivalence 
formula 1:31 
relation V:368 
term 1:31 

equivalence 1:20,111:162 
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euclidian ring V:374 
evaluator 

model IV:330 
unit 111:230, IV:330 
existential 

equation 1:8,22,111:164 
quantification 1:19, 111:160 
expansion of formula, term 1:21, 31, 
111:162 
explicit 

embedding 1:32 
qualification 1:46 
exponentiation 11:108 
expression, unit 1:54, 111:240, 255 
expressiveness, levels 1:65 
Ext. . . V:370 

extended 

signature 111:200 
specification V:368 
static semantics 111:247 
static unit context 111:249 
extends 

disjoint ly 111:248 
model 111:130 
extension 
Casl 1:68 
annotation 11:110 
Casl-Ltl 1:68 
coalgebraic 1:68 
CoCasl 1:68 

conservative annotation 1:39,11:110 
conservative 111:209 
Csp-Casl 1:69 

definitional annotation 1:39, 11:111 

definitional 111:209 

free 1:30, 34 

HasCasl 1:68 

HetCasl 1:69 

higher-order 1:68 

implicational 111:209 

implied annotation 1:39,11:111 

import 111:230 

monomorphic annotation 1:39, 
11:111 

monomorphic 111:209 
of a diagram 111:248 
of extended static unit context 
111:249 

reactive 1:68 



refinement language 1:69 
Sb-Casl 1:69 
signature morphism 111:199 
signature 111:125, 194 
specification 1:34, 36, 111:208 
structured level 1:69 
symbol map 111:196 
symbol mapping 1:35 
extension 1:36, 39 
extensions 

compatible 111:250 
free 1:36 

factorial ring V:374 
false 1:21 
falsity 111:163 
feature 

equality 1:65 
partiality 1:64 
predicate 1:64 

sort generation constraint 1:65 
subsorting 1:64 

features, orthogonal language 1:64 

field V:369 

final 

signature morphism 111:193 
signature union 111:194 
sink 111:194 
union 111:194 
finite map 111:116 
first-order 
logic 1:65 

many-sorted structure 1:7 
fitting 

argument list 1:42 
argument morphism 1:42 
argument specification 1:42 
argument view 1:45 
argument 1:56, 111:245 
compatible argument morphisms 
1:42 

morphism 1:35 
view 1:44, 111:218 
flat specification IV: 291 
halt enable IV: 294 
flattening 1:36 
floating-point number 11:108 
formal argument 111:245 
format, display 11:97, 98 
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formatting a comment 11:104 
formula 

atomic 1:8, 21, 31, 111:184 
definedness 1:22,111:164 
equivalence 1:31 
expansion 1:21,31,111:162 
membership 1:31,111:186 
satisfaction 111:136 
translation 111:134 
well-sorted 1:21,31,111:162 
formula 111:159 
fraction, decimal 11:108 
fragment 

signature 111:125 
union 111:125 

framework, basic specification 1:5 
free 

algebra V:374, 377 
datatype declaration 1:16,30,39, 
111:152, 178 
extension 1:30, 34 
extensions 1:36 
monoid V:374 
specification 1:36, 39, 111:209 
variable 111:133 
full subsignature 111:196 
fully- qualified 
symbol 111:195 
term 1:8,111:131 
function 

completion 111:117 
generic unit 1:52 
graph 111:116 
partial, symbol 1:6,111:124 
partial 1:7,111:116,128 
persistent 111:229 
profile 1:6,111:124 
qualified symbol 111:126 
total, symbol 1:6,111:124 
total 111:116, 128 
unit type 1:50 
unit 1:49, 111:227 

generalized positive conditional logic 
1:66 
generated 

datatype declaration 1:17 
signature 111:197 
sort 111:137 



generated 1:9 

generating signature morphism 111:193 
generation, sort 1:17,111:157, 183 
generative 

model semantics IV:338 
semantics 111:262 
generic 

context IV:334, 348 
signature 111:202 
specification definition 1:41 
specification import 1:35 
specification instantiation 1:34, 
111:214 

specification 1:40, 111:202, 212 
unit function 1:52 
unit signature IV:330 
unit specification IV:330 
unit 111:229 
view instantiation 1:45 
generic 1:34 

Gentzen-style IV:277, 282 
global 

annotation 11:105 
compatible environments 111:266 
directory 1:57, 111:267, 268 
environment, verification IV:316, 
358 

environment 1:34, 51, 57, 58, 111:204, 
266 

model environment 111:266 
static environment 111:266 
variable declaration 1:17, 111:158 
globally reachable IV: 293 
grammar 

abbreviated 11:81 
context-free 11:75, 87 
derived 11:95 
normal 11:76 
graph 

homomorphism V : 373 
of a function 111:116 
properties V:373 
graph V:372 
group 

action V:374 
symmetric V:376 
group V:369 
grouping 

annotation 11:103 
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braces 1:36 
comment 11:103 
mixfix analysis 11:88, 93, 95 
guaranteed property 1:49 

HasCasl extension 1:68 
HetCasl extension 1:69 
Hets V:364 
hiding 

reduction 1:37 
signature 1:34 
unit parts 1:55 
hiding 1:35, 40, 111:206 
higher-order extension 1:68 
homomorphism 

many-sorted 1:7,111:129 
homomorphism 1:5 
HTML 

annotation 11:106 
comment 11:105 

idempotency 
attribute 1:12 
idempotency 111:143 
identifier 

compound translation 1:47 
compound 1:47, 11:96, 111:223 
mixfix 1:25, 11:96 
qualified 1:46 
unqualified 1:23 
identifier 1:23, 25, 111:165, 168 
identity 
map 1:47 
translation 1:37 
implication 
reverse 1:20 
implication 1:20, 111:161 
implicational extension 111:209 
implicit 

associativity annotation 11:108 
embedding 1:32 
implied 

axiom annotation 11:110 
extension annotation 1:39,11:111 
import 

extension 111:230 
generic specification 1:35 
specification 1:41 
unit 111:235, 254 



view 1:43 
imported unit 1:52 
inclusion 

signature 111:127, 194 
subsort 111:169 
incomplete IV:308 
incompleteness 

of rules for development graphs 
IV:308 

incompleteness IV:277, 285 
inconsistency, accidental 111:181 
inconsistent 

generic unit specification IV:330 
specification IV:330 
inconsistent 1:6 

independence, institution 111:190 
indirect link 1:60 
induction rule IV: 280 
infer 1:5 

inference, preserve 1:6 
infix precedence 1:24 
initial model 1:34, 40 
input syntax 11:97 
instantiation 

generic specification 1:34, 111:214 
generic view 1:45 
pushout 111:200 
specification 1:42 
subsort preservation 1:48 
instantiation 1:42, 47 
institution 

Case, with qualified symbols 
111:190 

Case, with symbols 111:191 
comorphism IV:291 
independence versus proof calculus 
IV:290 

independence 111:190, IV:276, 290 
independent semantics 111:120 
institution 1:5,111:123 
integer V:366 
integral domain V:369 
intended consequences IV:276 
interface 1:49 
Internet 1:57 

irreducible element V:370, 375 
ISO Latin-1 11:97 
isomorphism 

declaration 1:29, III: 176 
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isomorphism 111:131 
item, basic 1:9 

kernel 

language of structured specifications 
IV:289 

language IV: 289 
kernel 111:116 
key word, sign 11:97, 98 
kind of syntactic entity 11:75 

label annotation 11:106 
LALR(l) 11:88 
language 

for naming sublanguages 1:61 
kernel IV: 289 
orthogonal features 1:64 
refinement extension 1:69 
regular 11:97 
largest subsignature 1:35 
RTeX 

annotation 11:106 
comment 11:105 
layout 11:97 
Leibniz formula V:376 
levels of expressiveness 1:65 
lexical 

analysis 11:88, 97 
symbol 11:88, 97 
lexicographical order 1:59 
library 

concept 1:57 
definition 1:58 
distributed 1:58 
local 1:58 
name 1:59, 111:267 
primary location 1:59 
specification 1:57 
version 1:59 
library 111:266 
linear 

algebra V:375, 377 
combination V:376 
visibility 1:6, 10, 51, 57, 58, 111:139 
link 

definition IV: 293 
direct 1:59 
indirect 1:60 
theorem IV:295 



list 

annotation 11:109 
fitting argument 1:42 
of symbols 1:46 
symbol map 1:46 
symbol 111:221 
list V:371 

literal syntax annotation 11:108 

LL(1) 11:88 

local 

associativity annotation 11:108 
assumption IV: 280 
axiom IV: 293 

environment 1:6, 34, 58, 111:138, 204 
implication IV: 295 
library 1:58 

specification 1:36, 40, 111:210 
unit 1:56, 111:244, 259 
variable declaration 1:18, 111:158 
locally reachable IV: 294 
location, primary library 1:59 
logic 

atomic 1:67 
first-order 1:65 

generalized positive conditional 1:66 
positive conditional 1:65 
logic IV:276, 290 
logical connective 1:19,111:160 

machine number V:377 
many- sorted 

basic specification 1:9,111:138 
first-order structure 1:7 
homomorphism 1:7, 111:129 
model 1:7,111:128 
partial algebra 1:7 
reduct 1:7,111:130 
sentence 1:8,111:132 
signature morphism 1:7,111:126 
signature 1:6,111:124 
term 1:7,111:131 
map 

finite 111:116 
identity 1:47 
signature symbol 111:195 
symbol, induced by a signature 
morphism 111:195 
symbol 111:195, 222 
map V:371 
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mapping 

symbol extension 1:35 
symbol 1:35, 46 
matching 

of symbol maps 111:195 
of symbols 111:192 
mathematical sign 11:98 
matrix 

multiplication V:375 
matrix V:375 
‘maybe’-type V:371 
membership 

formula 1:31,111:186 
predicate 1:28 
symbol 111:172 
membership 1:31 

met a- not at ion, context-free grammar 
11:87 

minor of a graph V:374 
mixfix 

display annotation 11:106 
grouping analysis 11:88, 93, 95 
identifier 1:25, 11:96 
notation 1:25 
token 1:25 
model 

architectural specification 1:50 
architectural 111:230 
class semantics 111:189 
compatible 111:229 
composition 1:49 
evaluator IV :330 
extends 111:130 

family consistent with F IV:334, 
353 

global environment 111:266 
initial 1:34, 40 
many-sorted 1:7,111:128 
reduct 111:130 
semantics, generative IV:338 
semantics 111:119, 138 
subsorted 1:28,111:173 
universal environment 111:267 
model 1:5, 7, 28 
monoid 

action V:374, 375 
commut at i ve V : 3 74 
free V:374 
monoid V:369 



monomorphic 

extension annotation 1:39,11:111 
extension 111:209, IV:296 
morphism 

composition 111:117 
final signature 111:193 
fitting argument 1:42 
fitting 1:35 

many-sorted signature 1:7,111:126 
signature 1:6,35,111:196 
specification 1:35, 111:202 
subsorted signature 1:28 
morphism 1:5 
morphisms 

compatible fitting argument 1:42 
multi-line comment 11:104 
multiplication, matrix V:375 

name 

architectural specification 1:51 
library 1:59, 111:267 
of signature symbol 111:192 
qualified operation 1:24 
qualified predicate 1:22 
specification 1:41 
unqualified predicate 1:22 
view 1:44 
named 

specification definition 1:41 
specification 1:34, 40, 111:212, 266 
view 1:35, 43 
natural deduction IV:277 
negation 1:21,111:162 
negative premise 111:120 
‘no confusion’ 111:155 
‘no junk’ 111:155 
non-empty carrier 111:128 
non-generic unit 111:229 
non-linear visibility 1:6, 14, 111:147 
non-nested 

annotation 11:103 
comment 11:103 
nonterminal symbol 11:87 
normal grammar 11:76 
notation 

decimal 11:108 
mixfix 1:25 
number 

annotation 11:108 
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floating-point 11:108 
symbol 11:100 
version 111:267 
number V:365 

OBJ3 IV:287 

objects of a category 111:117 
obligation, proof IV:275 
observer V:371 
omission, parentheses 11:106 
operation 

application 1:23,111:166 
attribute 1:12,111:143 
declaration 1:11, 111:142 
definition 1:13,111:144 
embedding 1:28 
partial, definition 1:13 
partial, type 1:12 
profile 1:12, 111:142 
projection 1:28 
qualified name 1:24 
total, definition 1:13 
total, type 1:11 
type 1:11 

operation 1:7, 11, 111:124 
optional symbol 11:87 
oracle 

for conservative extension IV:309 
for free theorem links IV:309 
orbit V:375 
order 

lexicographical 1:59 
order-sorted approach 1:27 
order V :368 
origin, symbol 1:54 
orthogonal language features 1:64 
overloaded symbol 1:7, 46, 111:126 
overloading relation 1:27,111:170 

pair V:371 
parameter 

specification 1:34, 41 
view 1:43 

parentheses, omission 11:106 

parse tree 11:88 

parsing 

annotation 11:106 
context-free 11:88 
partial 



constructor 1:15 
function symbol 1:6,111:124 
function 1:7,111:116,128 
many-sorted algebra 1:7 
model semantics IV:339 
operation definition 1:13 
operation type 1:12 
order V:368 
selector declaration 1:16 
partiality feature 1:64 
path 

in a graph V:373 
path 11:101,111:267 
permutation V:376 
persistent 

function 111:229 
persistent 1:50, IV:330 
place-holder 1:25 
planar graph V:374 
polynomial V:374, 377 
positive 

conditional logic 1:65 
generalized conditional logic 1:66 
integer V:366 
postfix precedence 1:24 
pre- development graph IV:312 
precedence 

annotation 11:107 

architectural specification 11:94 

conditional 11:95 

formula 11:94 

function application 11:94 

infix 1:24, 11:95 

mixfix 1:24 

postfix 1:24, 11:94 

prefix 1:24, 11:95 

rule 1:36 

structured specification 11:94 
term 11:94 

preceding annotation 11:104 
predicate 

application 1:8,21,111:163 
declaration 1:13, 111:146 
definition 1:14,111:147 
feature 1:64 
membership 1:28 
profile 1:6, 14, 111:124 
qualified name 1:22 
qualified symbol 111:126 
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symbol 1:6,111:124 
type 1:14, 111:147 
unqualified name 1:22 
predicate 1:7,13,111:128 
prefix precedence 1:24 
presentation 1:6, IV:291 
preservation 

subsort by instantiation 1:48 
preserve 

inference 1:6 
satisfaction 1:6 
primary library location 1:59 
principle, ‘same name, same thing’ 

1:36, 38 

product, scalar V:375 
production rule 11:75, 87 
profile 

function 1:6,111:124 
operation 1:12,111:142 
predicate 1:6, 14, 111:124 
projection 

operation 1:28 
subsort 1:32 
symbol 111:172 
proof 

calculus IV:275, 289, 347 
obligation IV:275, 276, 293, 295 
rule IV:280 

rules for development graphs IV: 298 
system 1:5 
property 

assumed 1:49 
guaranteed 1:49 
pushout 

construction 1:35 

for instantiation 111:200 

selected IV :330 

qualification, explicit 1:46 
qualified 

constant 1:24 
function symbol 111:126 
identifier 1:46 
operation name 1:24 
predicate name 1:22 
predicate symbol 111:126 
symbol 1:7 

symbols, Casl institution with 
111:190 



variable 1:23, 111:166 
quantification 

existential 1:19,111:160 
unique-existential 1:19,111:160 
universal 1:19, 111:160 
quantification 1:19 
quoted 

character token 11:100 
string symbol 11:100 

rational number V:367 
reactive extension 1:68 
real number V:366 
reduct 

many-sorted 1:7,111:130 
model 111:130 
subsorted model 111:174 
reduct 1:6,35,111:130 
reduction 
hiding 1:37 
revealing 1:37 
specification 1:36 
unit 1:55, 111:243, 258 
reduction 1:37, 111:206 
reference 

architectural specification 1:51 
specification 1:34, 111:266 
reference 1:57 

refinement language extension 1:69 
reflexive relation V:368 
regular language 11:97 
regularity condition 1:27 
relation 

overloading 1:27, 111:170 
satisfaction 111:123 
relation V :368 
remainder V:375 
renaming unit parts 1:55 
repeated declaration 1:10 
repetition 

symbol 11:87 
syntactic 11:75 
requirement specification 1:49 
reserved word, sign 11:98 
restriction, unit 1:55 
result sort 1:6,111:124 
reuse, specification 1:57 
revealing 

reduction 1:37 
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revealing 111:206 
reverse implication 1:20 
rich specification V:368 
ring 

euclidian V:374 
factorial V:374 
ring V:369 
RTF 

annotation 11:106 
comment 11:105 
rule 

derivation IV: 280 
elided 111:120 
precedence 1:36 
production 11:75, 87 
proof IV:280 
semantic 111:119 

‘same name, same thing’ 
principle 1:36, 38 
satisfaction 

of a formula 111:136 
of a sentence 111:137 
of a sort-generation constraint 
111:137 
preserve 1:6 
relation 111:123 
subsorted 111:175 
two- valued 1:8 
unit type 1:53 
satisfaction 1:5, 8, 111:135 
Sb-Casl extension 1:69 
scalar product V:375 
scope, variable declaration 1:18 
second-order logic IV:285 
selected pushout IV:330 
selector 

partial declaration 1:16 
total declaration 1:16 
self-contained specification 1:36, 58 
semantic 

annotation 11:110, 111:208, IV:296 
domain 111:118 
rules 111:119 
sharing 111:242 
semantically follows IV: 283 
semantics 

applicative 111:262, IV:338 
basic specification 1:6 



extended static 111:247 
generative 111:262 
institution-independent 111:120 
model class 111:189 
model 111:119, 138 
partial model IV:339 
static 1:54,111:118,138 
structured specification 1:34 
semantics 1:6,111:115 
sentence 

many-sorted 1:8,111:132 
satisfaction 111:137 
subsorted, translation 111:174 
subsorted 1:28,111:174 
sentence 1:5, 7, 28 
sequence 

alternative 11:87 
symbol 11:87 
sequence 111:116 
set 

carrier 1:7,111:128 
character 11:97 
symbol 1:35 
set 111:116, V:371 
shared symbol 1:43 
sharing 

between symbols 1:54 
semantic 111:242 
shortest path V:373 
sign 

key 11:97, 98 
mathematical 11:98 
reserved 11:98 
token 11:99 
unreserved 11:98 
sign V:376 
signature 

architectural 111:228 
cogenerated 111:198 
current 1:34, 111:204 
declaration 1:10, 29, 111:140 
diagram 111:248 
empty 111:193 
extended 111:200 
extension 111:125, 194 
final morphism 111:193 
fragment union 111:125 
fragment, subsorted 111:170 
fragment 111:125 
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generated 111:197 
generic 111:202 
hiding 1:34 

inclusion, subsorted 111:171 
inclusion 111:127, 194 
many-sorted morphism 1:7 
many-sorted, morphism 111:126 
many-sorted 1:6,111:124 
morphism induced by a symbol map 
111:199 

morphism, extension 111:199 
morphism, generating 111:193 
morphism, subsorted 111:171 
morphism, transportable IV:304 
morphism 1:6, 35, 111:196 
morphisms leaving names unchanged 
111:195 

morphisms, compatible 111:195 
morphisms, union 111:196 
subsorted fragment union 111:170 
subsorted morphism 1:28 
subsorted 1:27,111:169 
symbol map 111:195 
symbol 111:191 
symbols 111:126 
translation 1:34 
union, final 111:194 
union 111:193 
unit 111:228 
signature 1:5, 6, 27 
simple datatype V:370 
single-line 

annotation 11:105 
comment 11:104 
sink 

final 111:194 
sink 111:194,250 
site 1:57, 111:267 
smallest subsignature 1:35 
sort 

argument 1:6 
component 1:16 
declaration 1:10,11,111:141 
generation constraint feature 1:65 
generation 1:17, 111:137, 157, 183 
result 1:6,111:124 
sort-generation constraint 
satisfaction 111:137 



sort-generation constraint 1:8, 9, 
111:134 

sort 1:6, 10, 29 

sorted term 1:24,111:167 

sorts 

argument 111:124 
sorts 111:124 
sound IV:283 
soundness 

for the extended static semantics 
IV:338 

of extended static semantics 111:262 
of rules for development graphs 
IV:308 

soundness IV:277, 353 
space 11:97 
spanning tree V:373 
specialize 1:36 
specification 

architectural definition 1:51, 111:232, 
251 

architectural model 1:50 
architectural name 1:51 
architectural reference 1:51 
architectural unit 1:53, 111:239 
architectural 1:49, 50, 111:227, 232 
argument 1:34 

basic architectural 1:51, 111:233, 252 

basic concept 1:5 

basic framework 1:5 

basic many-sorted 1:9 

basic semantics 1:6 

basic subsorted 1:27 

basic 1:5,111:123 

body 1:34, 41 

closed unit 1:53, 111:239 

closed 1:34, 36, 40, 111:210 

definition 1:40, 111:211, 266 

empty 1:9 

extension 1:34, 36, 111:208 

fitting argument 1:42 

free 1:36, 39, 111:209 

generic definition 1:41 

generic import 1:35 

generic instantiation 1:34, 111:214 

generic 1:40, 111:202 

import 1:41 

in comment 11:105 

inconsistent IV :330 
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instantiation 1:42 
library 1:57 
local 1:36, 40, 111:210 
many-sorted basic 111:138 
methodology V:363 
morphism 1:35, 111:202 
name 1:41 

named definition 1:41 
named 1:34, 40, 111:266 
parameter 1:34, 41 
reduction 1:36 
reference 1:34, 111:266 
requirement 1:49 
reuse 1:57 

self-contained 1:36, 58 
structured semantics 1:34 
structured 1:33, 36, 111:204 
structuring 1:33 
subsorted basic 111:175 
subsorted 111:169 
subsorting 1:27 
translation 1:36, 37 
union 1:34, 36, 38, 111:207 
unit definition 1:52, 111:237 
unit 1:52, 111:230, 237, 255 
start, no symbol 11:87 
static 

analysis tool 111:247 
context IV:330 
extended semantics 111:247 
global environment 111:266 
semantics of architectural specifica- 
tions IV:330, 333 
semantics 1:54,111:118,138 
unit context 111:228 
universal environment 111:267 
string 

annotation 11:109 
quoted symbol 11:100 
string V:371 

strong equation 1:8, 22, 111:164 
structure, many-sorted first-order 1:7 
structured 

datatype V:370 
specification semantics 1:34 
specification 1:33, 36, 111:204 
structuring 
concept 1:33 
specification 1:33 



sub context IV : 334 
subdiagram 111:248 
sublanguage 

naming language 1:61 
of Casl 1:61, 62 
subsignature 
closed 111:197 
full 111:196 
largest 1:35 
smallest 1:35 
subsorted 111:170 
subsignature 111:126, 194 
subsort 

alternative 1:30 
declaration 1:29, 111:176 
definition 1:29,111:176 
embedding 1:27,48,111:169 
inclusion 111:169 
preservation by instantiation 1:48 
projection 1:32 
subsort 1:27 
subsorted 

basic specification 1:27, 111:175 
enrichment 111:175 
model reduct 111:174 
model 1:28,111:173 
satisfaction 111:175 
sentence 1:28,111:174 
signature extension 111:170 
signature fragment 111:170 
signature inclusion 111:171 
signature morphism 1:28,111:171 
signature 1:27,111:169 
specification 111:169 
subsignature 111:170 
translation of sentence 111:174 
union of signature fragments 111:170 
subsorting 
concept 1:27 
feature 1:64 
specification 1:27 
substitution 
lemma IV: 283 
substitution IV:279 
symbol 

auxiliary 1:36 
embedding 111:172 
fully- qualified 111:195 
lexical 11:88, 97 
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list 1:46, 111:221 

map induced by a signature morphism 
111:195 

map list 1:46 
map, extension 111:196 
map, matching 111:195 
map 111:195,222 
mapping extension 1:35 
mapping 1:35, 46 
matching 111:192 
membership 111:172 
name 111:192 
no start 11:87 
nonterminal 11:87 
number 11:100 
optional 11:87 
origin 1:54 

overloaded 1:7,46,111:126 
partial function 1:6,111:124 
predicate 1:6,111:124 
projection 111:172 
qualified function 111:126 
qualified predicate 111:126 
qualified 1:7 
quoted string 11:100 
repetition 11:87 
sequence 11:87 
set 1:35 
shared 1:43 
signature 111:126, 191 
terminal 11:87 
total function 1:6,111:124 
symbol 1:5,111:191 
symbols 

Casl institution with 111:191 
sharing between 1:54 
symmetric 
graph V:373 
group V:376 
relation V:368 
syntactic 

component 11:75 
constructor 11:75 
entity kind 11:75 
repetition 11:75 
syntax 

abstract 11:73, 75 
concrete 11:73, 87 
input 11:97 



literal annotation 11:108 
system, proof 1:5 

task decomposition 1:49 
term 

cast 1:32,111:187 
conditional 1:24,111:168 
equivalence 1:31 
expansion 1:21,31,111:162 
fully- qualified 1:8,111:131 
many-sorted 1:7,111:131 
sorted 1:24,111:167 
unit compatibility 1:55 
unit 1:54, 111:242, 257 
well-sorted 1:31,111:162 
term 1:23,32,111:165, 187 
terminal symbol 11:87 
theorem link IV:295 
theory 

category 111:117 
morphism IV:291 
theory IV:291 
token 

mixfix 1:25 

quoted character 11:100 
sign 11:99 
word 11:99 
token 1:25, 11:99 
total 

constructor 1:15 
function symbol 1:6,111:124 
function 111:116, 128 
operation definition 1:13 
operation type 1:11 
order V:368 
selector declaration 1:16 
trailing annotation 11:104 
transitive 

closure V:373 
relation V:368 

translating development graphs along 
institution comorphisms IV:297 
translation 

compound identifier 1:47 
from structured specification to 
development graph IV:311 
identity 1:37 
of SP along cr IV:348 
of a constraint 111:134 
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of formula 111:134 
signature 1:34 
specification 1:36, 37 
subsorted sentence 111:174 
unit 1:55, 111:242, 257 
translation 1:6, 35, 37, 111:205 
transportable signature morphism 
IV:304 

tree 

parse 11:88 
tree V:371, 373 
true 1:21 
truth 1:21, 111:163 
tuple 111:116 
two complement V:377 
two- valued satisfaction 1:8 
type 

enumeration 1:17 
operation 1:11 
partial operation 1:12 
predicate 1:14,111:147 
total operation 1:11 
unit function 1:50 
unit satisfaction 1:53 
unit 1:53, 111:238 

undefined value 1:8 
undirected graph V:373 
union 

disjoint 1:30,111:117 
final 111:194 

of signature fragments 111:125 
of subsorted signature fragments 

111:170 

signature morphisms 111:196 
signature, final 111:194 
signature 111:193 
specification 1:34, 36, 38, 111:207 
subsorted signature fragments 
111:170 

unique factorization V:375 
unique-existential quantification 1:19, 
111:160 

unit 

amalgamation 1:55, 111:244 
application 1:56, 111:245, 260 
architectural specification 1:53 
argument 111:245 
attribute 1:12 



closed specification 1:53 
compatible 111:229 
composition 1:54, 111:227 
context 111:231 

declaration 1:51, 52, 111:235, 253 
definition 1:51, 52, 111:236, 254 
dependencies 111:248 
element V:370 
environment 111:230 
evaluator 111:230, IV:330 
expression 1:54, 111:240, 255 
family consistent with F IV:353 
function type 1:50 
function 1:49, 111:227 
generic function 1:52 
generic 111:229 
hiding parts 1:55 
import 1:52, 111:235, 254 
local 1:56, 111:244, 259 
non- generic 111:229 
reduction 1:55, 111:243, 258 
renaming parts 1:55 
restriction 1:55 
signature 111:228, IV:330 
specification definition 1:52, 111:237 
specification, architectural 111:239 
specification, closed 111:239 
specification, generic IV:330 
specification, inconsistent generic 
IV:330 

specification 1:52, 111:230, 237, 255 
term compatibility 1:55 
term 1:54, 111:242, 257 
translation 1:55, 111:242, 257 
type satisfaction 1:53 
type 1:53, 111:238 
unit 111:143 
universal 

compatible environments 111:268 
model environment 111:267 
quantification 1:19,111:160 
static environment 111:267 
unqualified 

identifier 1:23 
predicate name 1:22 
unreserved 
sign 11:98 
word 11:98 

URL 1:59,11:101,111:267 
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valid object 111:118 
value 

of a term 111:135, 136 
undefined 1:8 
variable 

capture problem IV:280 
declaration scope 1:18 
declaration 1:18 
free 111:133 

global declaration 1:17, 111:158 
local declaration 1:18, 111:158 
qualified 1:23,111:166 
variable 1:17 
vector 

space V:375, 377 
vector V:375 
verification 

global environment IV:316, 358 
semantics IV:276, 289, 312 
version 

library 1:59 
number 1:59, 111:267 
view 

definition 1:43, 111:216, 217 



fitting argument 1:45 
fitting 1:44, 111:218 
generic instantiation 1:45 
import 1:43 
name 1:44 
named 1:35, 43 
parameter 1:43 
view 1:43, 111:203 
visibility 

linear 1:6, 10, 51, 57, 58, 111:139 
non-linear 1:6, 14, 111:147 

weakly amalgamable cocone IV: 289, 
291, 349 

well-formedness 1:9 
well-sorted formula, term 1:21, 31, 
111:162 

word 

key 11:97, 98 
reserved 11:98 
token 11:99 
unreserved 11:98 

zero divisor V:370 
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